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Automated  data  processing  on  smaller  platforms  was  implemented  with  the  SNAP 
II  program.  While  serving  many  of  the  same  functions  this  implementation  was  designed 
separately  and  for  a  different  user  group. 

The  SMMS  program  discussed  here  in  a  case  format  was  an  attempt  to  consolidate 
and  enhance  the  two  SNAP  programs. 
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I.  INTRODUCTION 


A.  THE  TOPIC 

This  thesis  will  point  up  some  of  the  many  and  often  conflicting 
influences  that  impact  on  management  information  system  and 
programming  decisions  in  the  naval  environment.  These  trends  and 
pressures  are  presented  in  a  case  study  setting  with  enough  background 
material  to  allow  the  reader  to  grasp  the  complexity  of  the  situation. 
Rather  than  espousing  one  right  answer  the  reader  should  come  away  with 
personal  solutions  that  will  aide  them  in  confronting  similar  projects. 

B.  BACKGROUND 

The  first  automated  non-tactical  systems  to  go  to  sea  were  designed  to 
provide  supply  and  financial  functions  for  auxiliary  ships.  These  systems 
kept  track  of  material  carried  on  board  but  belonging  to  an  ashore  activity. 
They  also  provided  record  keeping  for  the  ship’s  own  financial  and  supply 
requirements.  This  first  system  was  called  SNAP  I  for  Shipboard  Non- 
tactical  Automated  Data  Processing.  The  system  ran  on  a  mainframe 
computer  in  batch  processing  mode.  The  initial  system  used  punch  cards 
and  reports  and  financial  data  tended  to  be  about  a  week  behind  the  actual 
transactions.  Subsequent  upgrades  in  hardware  and  software  have  moved 
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some  ships  and  shore  stations  to  the  current  version  known  as  Shipboard 
Uniform  Automated  Data  Processing  System-Real  Time  (SUADPS  RT)(PRC, 
1991)  or  SNAP  I  release  three.  The  real  time  in  the  name  implies  that  the 
processing  is  almost  instantaneous  after  the  transaction  is  input  to  the 
system.  Although  some  might  argue  that  the  system  only  simulates  a  real 
time  mode,  since  transactions  update  copies  of  data  files  on  a  real  time 
basis.  Actual  updates  of  the  master  financial  and  inventory  files  are 
modified  in  batch  updates  on  a  daily  basis.  This  situation  is  somewhat 
analogous  to  a  deposit  in  an  automatic  teller  machine  where  your  balance 
is  shown  with  the  deposit  added  but  a  lower  balance  will  be  shown  if  the 
machine  is  immediately  rechecked.  The  new  higher  balance  will  only  show 
again  after  the  deposit  envelope  has  been  opened  and  the  master  record 
updated. 

Subsequent  to  SNAP  I,  SNAP  II  was  designed  to  provide  the  financial 
and  inventory  record  keeping  portion  of  SNAP  I  that  applied  to  smaller 
ships  onboard  spares  inventory  and  consumable  items.  In  SNAP  I  the 
similar  section  was  called  own  ships  use.  SNAP  II  was  designed  for  ships 
using  micro  or  mini  computer  hardware,  afloat  accounting  and  far  fewer 
staff  people  to  run  it.  The  financial  section  of  the  small  ships  system  was 
simpler  since  these  ships  were  only  required  to  maintain  internal  budgets. 
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operating  target  (OPTAR)  logs  and  end  use  stock  records;  and  did  not 
require  accounts  for  wholesale  and  retail  stocks  EUid  costs  for  tended  vessels. 
These  financial  record  systems  also  represent  simplified  afloat  accounting 
rather  than  the  more  complex  shore  station  system  used  in  SNAP  I.  This 
more  complex  shore  accounting  used  in  the  SNAP  I  systems  stems  from  the 
fact  that  the  majority  of  the  inventory  controlled  actually  belongs  to  the 
Navy  Stock  Fund  and  is  not  the  property  of  the  ship. 

The  two  SNAP  systems  perform  many  of  the  same  functions  with 
regard  to  internal  ships  supply  functions.  Despite  the  seeming  functional 
similarities,  each  system  was  developed  separately  for  different  hardware 
configurations.  Designing  to  these  hardware  differences  5delded  systems 
with  little  in  common  with  regard  to  how  they  "look  and  feel"  from  the 
human  interaction  standpoint.  For  example,  the  Storekeeper  (SK)  rating 
has  had  two  sets  of  questions  in  the  advancement  exams  representing  how 
functions  are  symbolized  and  performed  on  the  two  systems.  Of  concern 
from  a  manpower  assignment  perspective  is  that  a  junior  SK  is  much  more 
likely  to  have  hands-on  training  in  the  SNAP  II  system  but  he  or  she  is  apt 
to  be  subsequently  asked  to  supervise  on  a  SNAP  I  afloat  platform  or  shore 
activity  without  any  real  background.  This  requirement  for  two  separate 
training  pipelines  has  been  a  motivator  for  standardizing  as  many  functions 
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as  possible  between  the  two  systems.  The  possible  cost  savings  from 
reducing  the  number  of  systems  being  maintained  is  also  a  motivator  in 
funding  constrained  environment  of  the  early  1990s. 


The  differences  between  the  two  SNAP  systems  are  reflected  in  the 
parallel  organizational  structures  maintained  to  supervise  them.  All 
surface  and  submarine  type  commanders  maintain  separate  internal 
organizations  to  provide  guidance  to  supervised  activities  using  each 
system.  The  experience  sought  in  staff  and  the  guidance  given  to 
subordinate  activities  varies  widely  between  SNAP  I  and  SNAP  II 
organizations. 


C.  SOURCES  OF  INFORMATION 

Due  to  the  lack  of  literature  in  the  area  of  SNAP  I  and  SNAP  II 
consolidation,  the  majority  of  scurces  of  information  were  personal 
interviews  conducted  at  Navy  Management  System  Support  Office 
(NAVMASSO)  in  June  of  1991  and  follow-up  phone  calls  to  NAVMASSO 
and  Naval  Supply  Systems  Command  Fleet  Support  Division  (NAVSUP 
04D).  Further  input  was  obtained  from  vendor  product  documentation, 
articles  in  current  computer  periodicals.  Navy  notices  and  instruction  and 
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survey  data  collected  from  Type  Commanders  in  the  Atlantic  and  Pacific 
fleets  and  the  Marine  Corps  by  NAVSUP  in  the  fall  of  1991. 
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II.  CASE  METHODOLOGY 


A.  CASE  STUDY  FOR  RESEARCH 

A  case  study  "investigates  a  contemporary  phenomenon  within  its  real 
life  context;  when  the  boundaries  between  phenomenon  and  context  are  not 
clearly  evident;  and  multiple  sources  of  evidence  are  used.'XYin,  1989) 

The  appropriate  subject  matter  for  a  good  case  may  be  a  cutting  edge 
problem  not  yet  faced  by  many  business  leaders.  Most  cases  should  center 
on  common-place  problems  routinely  faced  by  managers.  (Culliton,  n.d.) 

A  case  study  attempts  to  capture  a  snapshot  of  an  organizational 
situation  as  it  unfolds,  without  imposing  experimental  controls.  In  a  case, 
an  observer  attempts  to  see  the  invisible  forces  acting  in  and  on  an 
organization  through  the  observable  actions  of  individuals.  (Lee,  1986) 

B.  TYPES  OF  CASES 

Culliton  (1973)  groups  cases  into  three  general  types  based  on  the 
degree  of  problem  specificity.  The  first  and  generally  the  shortest  is  the 
specific  problem  case.  These  cases  are  quite  specific  about  the  nature  of  the 
problem  and  who  has  the  problem.  The  second,  longer  type  is  the 
diagnostic  case.  In  these  cases  fact  that  someone  has  a  problem  is  less  clear 
cut.  The  specifying  of  the  problem  and  tne  person  or  persons  having  the 
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problem  is  more  open  to  interpretation  than  in  the  specific  problem  case. 
The  third  type  and  usually  longest  is  the  appraisal  case.  In  this  type 
readers  may  clearl>  disagree  on  whether  there  is  a  problem  or  not.  The 
topic  of  discussion  will  include  the  alternative  of  not  changing  anything. 
"Prognosis  may  be  more  important  than  diagnosis." 

Bennett(Davis  ,n.d.)  takes  a  somewhat  more  restrictive  view  on  types 
of  cases.  His  two  categories  of  cases  are  both  closely  related  to  the  specific 
problem  case.  The  first  type  is  the  issue  case  in  which  the  author  presents 
a  problem  and  the  reader  develops  scenarios  to  solve  it.  The  second  type  is 
the  appraisal  case  where  the  author  describes  a  management  solution  used 
and  the  reader  critics  the  solution. 

Both  authors  agree  that  the  time  span  of  a  case  is  specific.  The  span 
covered  should  be  decided  and  events  happening  after  the  period  covered 
should  be  excluded.  Only  in  such  a  limitation  can  a  realistic  problem 
solving  situation  be  created. 

C.  ADVANTAGES  OF  TEACHING  CASES 

Proponents  of  the  case  study  method  of  teaching  feel  that  the  quality 
and  quantity  of  material  retained  by  the  student  is  larger  when  the  case 
method  is  used.  The  advantages  are  attributed  to  information  fallout 
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phenomena.  The  fallout  results  from  the  students  seeing  an  immediate 
application  of  and  use  for  the  information  received.(CulIiton,  1973) 

The  use  of  qualitative  data  and  descriptions  can  be  an  advantage  in 
the  case  study  method.  Descriptions  of  situations  and  context  can  give  the 
reader  a  greater  perception  of  the  nature  of  real  life  decision  making.  Such 
rich  descriptions  can  stir  the  readers  imagination  more  readily  than  bare 
numerical  data.(Miles,  1984) 

A  case  study  method  teaches  the  student  that  there  is  often  more  than 
one  viable  altemative.(Pascale,  1973)  The  habits  of  diagnosing  problems, 
analyzing  and  evaluating  alternatives  and  developing  possible  responses 
have  value  in  their  own  right.(Harvey,  1988)  The  case  method  can  also 
illustrate  the  influence  of  political  power  on  decision  making.(Lee,  1986) 

Skills  learned  in  dealing  with  the  case  methodology  can  be  particularly 
valuable  in  the  information  systems  arena.  The  rapid  rate  of  technological 
change  and  innovation  in  the  information  system  area  have  a  continuing 
impact  on  organization  and  management.  The  deductive  skill  and  insights 
gained  through  the  use  of  cases  can  provide  excellent  preparation  for 
change.(Benbasat,  1987) 
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D.  DISADVANTAGES  OF  CASE  STUDIES 


The  use  of  qualitative  data  can  be  a  disadvantage  of  case  studies 
particularly  when  they  are  used  for  research.  Qualitative  data  in  case 
studies  tends  to  be  very  difficult  for  a  follow  on  researcher  to  duplicate  and 
thus  verify.(Lee,  1986)  Standardized  methods  of  analysis  for  qualitative 
data  are  lacking.(Miles,  1984) 

Data  collection  methods  for  case  studies  can  be  time-consuming  and 
require  extensive  documentation.  Even  if  abbreviated  methods  of  data 
collection  are  use,  production  of  a  quality  case  study  is  a  difficult  endeavor. 
No  proven  criteria  have  been  developed  to  determine  if  an  author  has  the 
requisite  skills  to  write  a  quality  case  study.  Yet  critics  argue  that  results 
obtained  can  only  be  generalized  with  extreme  care.(Yin,  1989) 
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III.  NON-TACTICAL  ADP  ENVIRONMENT 


A.  INTRODUCTION 

Traditionally  the  Navy  has  separated  the  automated  data  processing 
(ADP)  function  into  two  categories,  tactical  and  non-tactical.  The  Warner 
amendment  to  the  Brooks  act  and  the  paperwork  reduction  reauthorization 
act  of  1986  both  drew  a  distinction  in  the  equipment  covered  by  the  law 
based  on  application  within  the  Department  of  DefenseXMcDonough,  1990) 
Generally  ADP  applications  that  were  of  a  tactical  nature  or  part  of  a 
weapon  system  were  exempted  and  thus  subject  to  fewer  regulatory 
guidelines.  On  the  non-tactical  side,  programs  and  applications  are  subject 
to  a  different  set  of  standards  and  require  more  extensive  justification  along 
cost  benefit  lines. 

The  net  effect  of  the  traditional  separation  was  to  have  distinct 
h£irdware  and  software  developments  in  the  two  areas.  The  people  who 
developed  the  two  types  of  systems  worked  at  different  activities  and 
seemed  to  have  little  in  common.  These  separations  were  heightened  by  the 
fact  that  tactical  systems  tended  to  be  organic  to  pieces  of  hardware  and  to 
be  either  real  time  or  interactive  in  nature.  Non-tactical  systems  on  the 
other  hand  originally  tended  to  be  based  on  large  mainframe  operations  and 
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were  batch  in  nature  or  else  they  were  stand  alone  and  used  largely  for 
word  processing. 

B.  ADP  DISTINCTIONS  DIMINISHING 

In  a  speech  to  the  September  1991  Navy  micro  computer  conference, 
the  Navy’s  senior  IRM  official,  Gerald  Cann,  addressed  current  trends  in 
Navy  ADP.(Green,  1991)  He  feels  that  the  old  differences  between  tactical 
and  non-tactical  hardware  and  software  are  diminishing.  In  parallel  with 
this  trend,  the  separation  in  the  procurement  methods  used  is  also 
decreasing. 

Custom  made  software  for  use  with  tactical  systems  is  being 
supplanted  by  off-the-shelf  packages.  This  trend  should  allow  the 
procurement  system  to  reduce  or  eliminate  the  distinctions  which  have 
confused  procurement  issues  dealing  with  tactical  and  non-tactical 
technology.  Cann  also  strongly  believes  that  the  acquisition  cycle  for 
computers  should  be  reduced  to  £in  18  month  turn  around.(Green,  1991) 

Robert  Green,  director  of  information  resources  interoperability  for  the 
Nav^s  Information  Technology  Acquisition  Center  gives  further  insight  into 
the  changes  taking  place.  In  1991,  the  data  processing  systems  in  ships 
tend  to  support  the  separate  activities  and  the  groups  supporting  those 
activities.(Robb,  1991)  If  a  part  fails  in  a  tactical  system  the  request  for  a 
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spare  part  would  first  go  to  the  division  maintenance  people  for  a  check  of 
the  ready  service  spares  bins.  If  it  is  not  found  the  search  would  be 
extended  to  supply  depeulment  stocks.  The  request  would  have  to  be 
entered  into  a  separate  supply  system.  Even  if  the  part  is  found  onboard, 
the  maintensince  action  performed  must  be  entered  into  a  separate 
maintenance  tracking  system.  If  the  part  is  not  found  and  the  equipment 
is  non-functional,  a  casualty  reporting  system  will  become  involved.  Mr 
Green  sees  an  integrated  environment  coming  where  the  failure  of  the  part 
and  the  required  responses  can  be  largely  automated  without  repeated 
intervention  in  the  form  of  duplicate  data  entry  into  parallel  systems.(Robb, 
1991) 

The  integration  of  tactical  and  non-tactical  networks  is  demanding  a 
new  level  of  cooperation  from  two  systems  commands,  NAVSEA  (Naval  Sea 
Systems  Command)  and  SPAWAR  (Space  and  Naval  Warfare  Systems 
Command).  NAVSEA  previously  dealt  mainly  with  problems  internal  to  the 
ship  while  SPAWAR’s  meiin  emphasis  was  on  problems  external  to  the 
ship.(Robb,  1991) 

Yet  another  perspective  can  be  gained  by  looking  at  the  changes  taking 
place  in  the  way  the  Navy  buys  ADP  equipment.  Captain  McQueen, 
commanding  officer  of  Information  Technology  Acquisition  Center  (ITAC) 
recently  gave  his  perspective.(Robb,  1991)  The  trend  in  industry  is  to  lower 
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the  barriers  between  telecommunications  and  computers.  It  would  be 
difficult  to  say  whether  the  move  toward  the  picture  phone  and  other 
broadband  communications  or  the  trend  toward  multimedia  and  distributed 
computing  is  the  main  driver  but  distinctions  are  blurring.  ITAC  will  be 
buying  both  base  telecommunications  systems  and  information  processing 
systems.(Robb,  1991) 

The  ITAC  staff  will  be  buying  the  $40  million  Tactical  Advanced 
Computer  (TAC-3)  procurement  as  well  as  the  SNAP-3  procurement,  now 
in  its  early  planning  stages(Robb,  1991). 

C.  PROGRAMMING  LANGUAGES 

In  1987  the  Defense  Department  issued  a  Directive  replacing  its 
earlier  1976  Instruction  on  Higher  Order  Languages  (HOL)  in  the 
Department  of  Defense.  The  directive  provides  policy  guideline  for 
computer  programming  languages  used  in  both  development  and  support 
of  DoD  softwareCDoD  3405.1,  1987). 

As  in  personal  computers  and  other  non-government  business 
applications  there  is  a  tradeoff  between  changing  to  the  latest  tool  and  the 
large  capital  investment  in  an  already  acquired  inventory  of  software.  The 
directive  attempts  to  balance  these  opposing  forces  while  limiting  the 
overall  number  of  HOLs  that  are  allowed.  The  main  thrust  of  the  limitation 
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is  to  support  the  goal  of  transition  to  the  use  of  Ada(MIL-STD-1815A,  1983) 
for  Department  of  Defense  software  development(DoD  3405.1,  1987). 

In  support  of  the  transition  goal  a  list  of  the  only  acceptable  HOLs  is 
included.  These  authorized  HOLs  can  be  used  to  complete  major  projects 
that  have  passed  milestone  IKDoD  5000.1,  1986).  In  these  and  other 
completed  projects  the  other  languages  can  be  used  subsequently  for 
software  maintenance  but  not  for  major  upgrades.  Other  authorized  HOLs 
may  also  be  authorized  for  projects  where  they  have  a  demonstrable 
advantage  over  Ada(DoD  3405.1, 1987).  This  advantage  should  be  in  terms 
of  life-cycle  cost  savings  and  fulfillment  of  system  requirements. 

The  Directive  states  preference  can  be  given  to  off-the-shelf  software 
and  advanced  software  technology.  However,  due  consideration  must  have 
been  given  to  the  future  impact  on  competition  for  software  and 
hardware(DoD  3405.1,  1987).  Use  of  the  new  technology  must  not  set  up 
future  sole  source  buy  situations  unfavorable  to  the  government. 

More  recent  events  seem  to  reinforce  the  stand  taken  by  DoD  on  Ada. 
In  1991  Paul  Strassmann,  director  of  defense  information,  asked  the  DOD’s 
Information  Technology  Policy  Board  to  evaluate  Ada  and  C++  which  is  not 
on  the  list  of  approved  HOLs(DoD  3405.1,1987)  and  recommend  whether 
DOD  should  use  C++  for  some  projects.  Five  contractors  prepared  reports 
with  their  efforts  coordinated  by  Lloyd  K  Mosemann,  deputy  assistant 


14 


secretary  of  the  Air  Force  for  communications,  computers  and 
logistics(Schwartz,  1991).  No  significant  reasons  were  found  to  "waive  the 
Ada  requirement"  in  favor  of  C++(Schwartz,  1991).  One  of  the  reporting 
contractors  TRW  Inc.  found  Ada’s  score  on  a  range  of  software  engineering 
issues  to  be  over  20%  higher  than  the  score  tabulated  for  C++.  This  same 
report  recommended  that  waivers  for  the  use  of  C++  at  least  through  1993 
only  be  granted  for  conversion  of  software  originally  written  in  C(Schwartz, 
1991). 

D.  TRENDS 

The  overall  trend  in  shipboard  computing  is  toward  consolidation  of 
systems.  The  smaller  number  of  hardware  and  software  systems  that  need 
to  be  supported  allows  economies  in  staffing,  lower  software  maintenance 
costs,  and  fewer  repair  part  requirements. 

DoD  is  attempting  to  consolidate  and  standardize  programming 
languages.  Streamlining  the  programming  of  new  systems  by  reuse  of 
previously  developed  code  should  save  money.  Ada  was  developed  with 
reuse  of  code  segments  as  a  basic  premise.  The  use  of  Ada  is  now  being 
expanded  from  tactical  applications  into  all  shipboard  applications. 
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IV.  SNAP  CONFIGURATION  MANAGEMENT 


A.  OBJECTIVES 

The  stated  objectives  of  SNAP  configuration  management  were: 

a.  To  assist  SNAP  program  management  in  achieving  the  most  cost- 
effective  performance,  operational  efficiency,  implementation  schedule, 
logistic  support  and  readiness. 

b.  To  attain  maximum  efficiency  in  the  management  of  engineering 
changes. 

c.  To  achieve  the  following  goals  at  a  system  level: 

(1)  To  ensure  that  verified  configuration  technical 
documentation  is  available  when  needed. 

(2)  To  maintain  hardware  and  software  standardization  and 
compatibility. 

(3)  To  ensure  that  total  performance,  costs,  and  schedule  impact 
of  change  proposals,  deviations,  and  waivers  are  known  at  the  time  of 
approval. 

(4)  To  ensure  that  all  hardware  and  software  configurations  are 
defined  and  that  pertinent  physical  and  functional  interfaces  between 
systems,  equipments,  and  software  programs  are  documented  and 
controlled.(SPAWAR  4130.12,  1986) 


B.  ORGANIZATION 

The  same  instruction  established  a  system  of  boards  and  committees 
to  carry  out  these  stated  objectives(SPAWAR  4130.12,  1986).  The  SNAP 
Joint  Configuration  Control  Boards  (JCCBs)  were  chaired  by  the  SPAWAR 
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SNAP  Program  Directorate  or  designee,  who  had  ultimate  authority  for  it’s 
decisions.  The  JCCBs  also  have  permanent  members  representing  the 
Commander  NAVSEASYSCOM  and  Commanding  Officer  Navy 
Management  System  Support  Office  (NAVMASSO).  The  SNAP  I JCCB  had 
additional  permanent  members  representing  Commander,  Naval  Air 
Systems  Command  (NAVAIR)  to  interface  on  matters  relating  to  Naval  Air 
Logistics  Command  Management  Information  System  (NALCOMIS), 
Commander,  Naval  Data  Automation  Command  (NAVDAC)  for  Type 
Commander  Headquarters  Automated  Information  System  (THAIS) 
matters,  and  a  non-voting  member  from  the  Automated  Data  Processing 
Selection  Office  (ADPSO)  to  advise  on  SNAP  I  contract  matters.  The 
JCCBs  further  had  Ad  Hoc  members  representing  SNAP  Functional 
Managers,  Chief  of  Naval  Education  and  Training  (CNET),  and  the  Fleet 
Commanders  in  Chief.  The  SNAP  I  JCCB  also  had  an  Ad  Hoc  member 
representing  the  Commandant,  Marine  Corps. 

Subordinate  to  the  JCCB  were  the  SNAP  Hardware  Configuration 
Control  Committees  (HCCCs).  The  Chairman  of  these  committees  and  final 
arbiter  on  any  matters  not  requiring  referral  to  the  JCCBs  was  Commander 
NAVSEASYSCOM  or  his  designee.  SPAWAR  as  the  SNAP  program 
manager  was  a  permanent  member  of  the  HCCCs  and  had  the  authority  to 
refer  proposals  to  the  JCCBs  for  decision.  The  other  permanent  members 
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were  representatives  of:  NAVMASSO  fleet  Central  Design  Agency  and 
Naval  Sea  Combat  Systems  Engineering  Station 
(NAVSEACOMBATSYSENGSTA)  as  In  Service  Engineering  Activity 
(ISEA).  The  SNAP  I  HCCC  also  had  permanent  members  representing 
NAVAIR  the  NALCOMIS  Program  Manager  and  a  non-voting 
representative  of  ADPSO  to  answer  questions  on  the  AN/UYK-65  hardware 
contract.  The  Ad  Hoc  members  of  the  HCCCs  were  representatives  of  at 
least  the  following:  Naval  Supply  Systems  Command  (NAVSUP)  to  insure 
proper  coordination  with  its  inventory  control  points,  CNET  as  SNAP 
training  interface  and  Fleet  Commanders  in  Chief  as  user  representatives. 
SNAP  I  HCCC  also  had  Ad  Hoc  members  representing  the  Commandant, 
Marine  Corps  as  a  user  and  NAVDAC  for  THAIS  interface. 

Also  subordinate  to  the  JCCBs  were  the  SNAP  Software  Configuration 
Control  Committees  (SCCCs).  The  Chairman  of  these  committees  and  final 
arbiter  on  any  matters  not  requiring  referral  to  the  JCCBs  was 
Commanding  Officer  Navy  Management  Support  Office  (NAVMASSO)  or 
his  designee.  SPAWAR  as  the  SNAP  program  manager  was  a  permanent 
member  of  the  SCCCs  and  again  had  authority  to  refer  proposals  to  the 
JCCBs  for  decision.  In  a  swapping  of  roles  from  the  HCCCs  another 
permanent  member  was  a  representative  of  NAVSEA  to  evaluate  the 
potential  impacts  of  changes  on  hardware  and  firmware. 
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NAVSEACOMBATSYSENGSTA  as  ISEA  was  again  a  permanent  member. 
The  SNAP  I SCCC  also  had  permanent  members  representing  NAVAIR  the 
NALCOMIS  Program  Manager,  Navy  Regional  Data  Automation  Center 
Norfolk  representing  THAIS  issues  and  a  non-voting  representative  of 
ADPSO  to  answer  questions  on  SNAP  I  contract  issues.  The  Ad  Hoc 
members  of  the  SCCCs  were  representatives  of  at  least  the  follov/ing: 
Commander  Naval  Supply  Systems  Command  (COMNAVSUPSYSCOM)  as 
SNAP  Functional  Manager,  CNET  as  SNAP  training  interface  and  Fleet 
Commanders  in  Chief  as  user  representatives.  SNAP  I  SCCC  also  had  Ad 
Hoc  members  representing  the  Commandant,  Marine  Corps  as  a  user. 

C.  RESPONSIBILITIES 

The  JCCBs  were  responsible  for  overall  policy  guidance  on 
prioritization  of  change  actions,  reporting  requirements,  and  general 
management  of  the  program.  They  were  also  responsible  for  announcing 
their  meetings  at  least  45  days  in  advance  to  allow  the  subordinate 
committees  to  publish  and  distribute  agenda  items  30  days  before  the 
meetings.  Issues  requiring  new  funding,  schedule  changes  or  not  limited 
to  Hardware  or  Software  areas  as  well  as  after  the  fact  reviews  of  the 
decisions  of  the  SCCCs  and  the  HCCCs  also  were  the  JCCBs  responsibility. 


The  HCCCs  were  responsible  for  hardware  and  firmware  configuration 
control,  record  keeping,  auditing  of  installations  and  monitoring  of 
contractor  configuration  management.  They  also  had  to  evaluate  integrated 
logistics  support  elements  and  funding  levels  before  implementing 
configuration  changes.  Finally  they  had  to  organize  and  research  and 
provide  recommendations  for  issues  that  were  to  be  referred  to  the  JCCBs 
for  resolution. 

The  SCCCs’  responsibilities  included  deciding  all  software  change 
issues  that  don’t  efiect  funding  levels,  scheduling  or  hardware.  They  also 
develop  procedures,  conduct  audits,  perform  configuration  status  accounting 
and  historical  record  keeping.  Finally  they  develop  schedules  and  priorities 
for  theii  area  of  responsibility. 


20 


V.  SNAP  MATERIAL  MANAGEMENT  SYSTEM  CASE  STUDY 

A.  CASE  SITUATION' 

In  August  1989  SMMS  project  manager  Margaret  Winston  at 
NAVMASSO  in  Norfolk  Virginia  assigned  Bobby  Jenkins  and  three  other 
ansdysts  to  start  data  modeling  and  analysis  of  the  SNAP  Material 
Management  System  (SMMS)  project.  This  initial  effort  was  centered 
around  the  Information  Engineering  Systems  Corporation  (EESC) 
methodology  and  was  assisted  by  one  of  a  series  of  rotating  contractor 
personnel. 

In  keeping  with  the  lESC  format,  emphasis  was  placed  on  data  not 
procedures  and  business  knowledge  rather  than  technology.  The  lESC 
CASE  tool  focuses  on  modeling  the  business  process  using 
Finkelstein'sCKeyes,  1992)  method  of  breaking  activities  down  into  fourth 
and  fifth  business  normal  form.  The  data  is  divided  and  then  grouped  into 
entities  which  represent  a  table  in  a  relational  data  base  in  fifth  normal 
form.  All  possible  relations  between  data  elements  are  defined  in  one  of 
these  tables.  This  separation  of  data  into  fifth  normal  form  permits  a 

'This  is  a  preliminary  version  of  a  case  study  which  has  not  yet 
been  approved  for  public  release.  It  is  not  for  republication  or 
quotation. 


21 


segregation  of  business  detail  into  objects.  These  objects  are  intended  to 
group  data  and  the  associated  relationships  and  interactions  between 
data(Keyes,  1992).  In  support  of  this  task  the  lESC  CASE  tool  generates 
numerous  reports  including  Entity  Report,  Entity  Purpose  Report, 
Association  Report,  Subject  data  base  implementation  priorities,  and 
Attribute  Report. 

Over  the  ten  months  of  the  modeling  effort,  Margaret’s  group  defined 
and  categorized  increasingly  complex  entity  models  until  three  hundred  and 
fifty  eight  active  entities  had  been  defined.  The  condensed  version  of  the 
first  four  reports  showing  only  active  entities  had  grown  to  one  hundred  and 
seventy  pages  by  mid  1991. 

In  the  twelve  months  of  the  DESC  contract,  twelve  different  consultants 
were  assigned.  One  of  the  first  DESC  consultants  with  some  non-specified 
informal  input  from  senior  officers  in  the  Washington  arena,  initially 
identified  the  following  twenty  five  business  functional  areas. 

•  Transaction  Access 

•  Organization  Identification 

•  Organization  Categorization 

•  Address 

•  Person 

•  Skill 
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•  Item  Identification 


•  Contract 

•  Customer  Need 

•  Performance  Monitoring 

•  Priority  Management 

•  Requisition  Status 

•  Supply  Requirement 

•  Supply  Requisition 

•  Item  Handling 

•  Location 

•  Requisition  Receipt 
•»  Item  Configuration 

•  Organization  Allowance  Level 

•  Organization  Item  Management 

•  Inventory  Physical  Distribution 

•  Item  Management 

•  Fund  Accounting 

•  Fund  Authorization 

•  Fleet  Freight  (NAVMASSO,  1991) 

At  a  more  tactical  level  the  business  functional  areas  were  grouped 
into  four  functional  areas  and  assigned  to  the  four  analysts  at  NAVMASSO 
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for  development  of  entities  within  areas.  Financial  was  first,  consolidating 
accounting  practices  under  ashore  and  afloat  rules.  Second  were  security 
concerns.  Requirements  and  inventory  control  were  third  and  fourth 
respectively.  Next,  end  user  input  was  solicited  from  seven  commands, 
each  one  level  above  actual  operational  units.  Each  of  these  commanders 
controlled  operational  units  using  either  SNAP  I  or  SNAP  II.  Group 
meetings  were  scheduled  and  held  on  both  co  '’ts  to  identify  the  basic 
entities  which  in  the  lESC  scheme  would  be  the  low  level  objects  and  the 
logic  that  acts  on  those  objects.  In  addition  to  basic  entities,  the  meetings 
were  to  develop  attributes  and  relationships  of  entities  as  well  as  edit  rules 
and  display  input  items.  Between  meetings,  the  NAVMASSO  analysts  and 
lESC  consultant  used  the  lESC  computer  aided  software  engineering  tool 
to  model  the  data  for  review  at  the  next  meeting. 

By  the  end  of  the  second  cycle  of  meetings  Bobby  and  the  other 
NAVMASSO  analysts  had  noticed  some  general  differences  in  viewpoint  in 
representatives  of  Atlantic  and  Pacific  fleets.  The  Atlantic  fleet 
representatives  seemed  to  expect  a  greater  amount  of  top-down  supervision 
and  less  flexibility  in  the  system  at  the  operational  level.  They  also 
expected  reports  to  higher  authority  to  contain  more  detail.  Finally,  the 
East  coast  representatives  modeled  a  system  where  more  help  was  extended 
down  the  chain  in  terms  of  outside  organizations  providing  supplemental 


24 


parts  tracking  services  and  similar  functions.  The  analysts  also  noticed 
that  representatives  of  the  submarine  community  saw  the  testing  records 
and  certification  of  nuclear  related  parts  as  a  top  concern  while  aviators 
seemed  more  concerned  with  tracking  the  return  of  equipments  for  repair. 

Successive  meetings  of  the  user  groups  encountered  weeks  of  delays 
due  to  varying  opinions  expressed  by  senior  storekeepers  and  supply  officer 
representatives  from  various  commands  and  from  representatives  of  the 
same  commands  at  successive  meetings.  More  than  once,  these 
disagreements  as  to  the  nature  of  basic  entities  to  be  modeled  negated  the 
majority  of  the  work  accomplished  at  a  preceding  meeting.  Disagreements 
among  participants  were  intensified  by  the  fact  that  the  meetings  tended 
to  alternate  between  coasts  with  Atlantic  fleet  participants  attending  east 
coast  meetings  and  Pacific  fleet  representatives  attending  west  coast 
meetings.  Since  the  Atlantic  and  Pacific  fleets  have  their  own  sets  of 
instructions  and  reporting  requirements  dealing  with  shipboard  supply 
procedures,  groups  from  these  two  fleets  tended  to  have  differing  views  on 
which  reports  were  required  and  what  procedures  were  critical  and  which 
superfluous.  Even  more  fhistrating  to  the  analysts  was  the  fact  that  even 
on  the  same  coast  the  changing  representatives  from  a  command  would 
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often  vary  in  their  views  from  meeting  to  meeting  thus  causing 
backtracking  and  reexamination  of  completed  areas. 

Despite  these  formidable  obstacles  to  progress,  the  analysts  were  able 
to  develop  cohesive  groups  of  entities  in  three  out  of  four  functional  areas 
by  the  fall  of  1990.  Financial  was  the  functional  area  not  completed, 
possibly  due  to  an  inability  to  resolve  the  differences  between  afloat  and 
ashore  accounting  practices.  With  this  exception,  the  analysts  believed  they 
were  ready  to  evaluate  the  SMMS  model  as  a  whole  with  the  end  users. 
Unfortunately  Operation  Desert  Storm  work  requirements  had  almost 
totally  depleted  the  pool  of  users  who  would  otherwise  do  the  evaluation 
and  the  project  went  into  a  holding  pattern. 

During  the  delay,  the  fact  that  the  computer  aided  software 
engineering  tool  in  use  was  centered  mainly  on  data  modeling  and  did  not 
provide  support  for  code  generation  was  reevaluated  by  the  project  steering 
committee.  In  order  to  take  advantage  of  potential  cost  savings  in  code 
generation  and  software  maintenance  costs,  CASE  tools  with  code 
generation  capability  were  considered.  Despite  the  fact  that  translation  of 
the  work  done  to  date  was  not  guaranteed  by  the  company,  the  decision  was 
approved  by  Admiral  Moore’s  committee  to  use  a  new  CASE  tool  for  the 
remainder  of  the  project.  lESC  who  had  been  in  on  the  data  modeling  work 
was  discharged  but  four  copies  of  their  software  were  purchased  with  the 
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idea  that  in-house  staff  could  maintain  the  data  model  already  developed 
and  to  aide  in  translation  to  the  new  model.  As  late  as  June  1991  only  one 
copy  of  the  software  had  actually  been  loaded  and  had  proved  of  limited 
utihty  in  the  transition  process. 

Three  new  integrated  CASE  tools  produced  by  Oracle  were  chosen. 
Oracle’s  tools  define  business  applications  instead  of  business  fimctional 
areas  as  a  starting  point.  The  twenty  five  business  functional  areas  were 
grouped  into  nine  business  applications.  The  first  three  of  nine  applications 
to  be  defined  and  the  first  to  be  worked  were  material  id,  organization, 
material  procurement.  Translation  of  work  completed  using  the  lESC 
CASE  tool  to  the  new  Oracle  CASE  tool  has  proven  difficult  at  best. 

In  order  to  more  clearly  define  fleet  requirements  Admiral  Moore 
directed  COMNAVSUPSYSCOM  to  survey  the  fleet  user.  Due  to  an 
imminent  transfer  by  the  Captain  in  charge  of  sending  the  survey,  an 
extensive  four-part  and  200  page  questionnaire  was  hastily  sent  out  to  all 
the  users  and  subsequently  reduced  in  scope  to  type  commanders  only.  The 
loose  organization  and  redundant  nature  of  the  questions  in  the  survey  as 
well  as  the  length  impair  its  usefulness.  The  initial  impact  was  to  delay 
any  further  user  input  meetings  by  two  to  six  months  pending  return  and 
evEiluation  of  survey  results. 
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B.  OTHER  CONSIDERATIONS 

The  Oracle  CASE  tool  generates  code  in  a  proprietary  language  SQL 
Forms  rather  than  Ada.  While  exceptions  to  the  use  of  Ada  as  a 
programming  language  in  DOD  could  be  obtained,  there  had  been  no 
commitment  to  use  SQL  Forms  for  other  non-tactical  shipboard 
applications.  SQL  Forms  was  also  not  listed  as  one  of  the  higher  level 
languages  approved  for  use  by  the  Department  of  Defense(DoD  3405.1, 
1987).  Use  of  a  non-standard  language  may  impede  future  communications 
between  and  integration  of  shipboard  systems. 

A  separate  group  of  analysts  at  NAVMASSO  was  working  on  a  project 
to  reverse  engineer  half  a  dozen  automated  shipboard  and  shore 
maintenance  tracking  programs.  These  programs  have  been  developed  by 
type  commanders  and  program  managers  to  track  maintenance  actions  on 
different  pieces  or  types  of  shipboard  equipment.  At  least  one  system 
developed  for  NAVSEA,  the  maintenance  resource  management  system 
(MRMS),  has  two  versions  one  for  SNAP  I  sites  and  one  for  no  i-SNAP  I 
sites(PRC,  1991).  Integration  of  these  programs  with  other  shipboard 
software  has  not  been  a  firm  requirement.  This  lack  of  interoperability  may 
be  due  to  the  lack  of  emphasis  and  non-availability  of  technology  at  the 
time  when  the  programs  were  developed.  The  analysts  are  attempting  to 
extract  and  preserve  the  best  parts  of  each  separate  system  in  a 
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standardized  system.  Even  though  this  system  will  need  to  communicate 
in  some  fashion  with  the  supply  software  no  commitment  had  yet  been 
made  to  any  data  model  or  specific  software. 

There  also  non-funded  long  term  goals  of  eventually  including  other 
supply  areas  as  well  as  shipboard  administrative  functions  in  a  centralized 
ships  data  baseCWinston,  1991).  While  these  considerations  have  not  yet 
received  the  credibility  of  being  funded  their  importance  may  increase  with 
the  continued  shift  toward  minimum  manning  and  maximum  efficiency  of 
shipboard  activities  and  equipment. 

In  June  1991,  no  consideration  had  been  given  to  a  direct  linking  of  the 
computerized  data  in  the  ship’s  co-ordinated  shipboard  allowance  list  with 
the  supply  module.  Such  a  link  might  help  insure  that  the  system  reflected 
the  latest  in  ships  on  board  equipment  and  likewise  was  not  ordering  parts 
for  equipment  that  had  been  removed  in  overhauls. 

The  Oracle  vendor  estimated  that  the  run  time  modules  needed  to  run 
their  proprietary  software  on  local  area  networks  (LANs)  on  ships  would 
run  about  $150  per  copy(Oracle,  1991).  The  SQL  Forms  language  had  no 
capability  to  communicate  with  CD  ROM  based  technology  for  updating  of 
price,  stock  number  or  other  data.  Due  to  the  decreasing  cost  and  highly 
portable  nature  of  CD  ROM  technology,  this  lack  of  compatibility  may  limit 
future  expansion. 
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Currently,  none  of  the  Navy’s  ashore  accounting  systems  have  been 
certified  by  the  GAO  mainly  due  to  the  lack  of  depreciation 
capability(Eberling,  1991).  The  data  requirements  of  such  a  new  system 
were  not  known  in  1991.  Thi«  lack  of  guidance  could  be  a  major  challenge 
to  progress  on  the  fin£inci£d  aspects  of  SMMS. 

SNAP  I  release  3  (realtime)  which  had  a  very  rocky  start,  with 
problems  encountered  in  its  processing  of  data  and  giving  immediate  or 
realtime  updates  to  data.  However,  release  3  is  starting  to  gain  more 
acceptance  by  the  pertinent  divisions  of  the  user  group  commandsCPeiite, 
1991).  Especially  when  compared  to  the  work  involved  and  risks  inherent 
with  building  and  installing  a  totally  updated  system.  Most  of  the  users 
have  been  involved  in  at  least  one  update  or  system  implementation  and 
know  that  every  time  a  major  change  is  made  to  a  system  there  are 
undetected  software  problems  that  must  be  fixed  retroactively.  In  an 
operational  environment  such  problems  with  supply  software  would 
interfere  with  the  units  ability  to  fix  broken  equipment  and  reduce  the 
supply  systems  credibility.  In  a  worst  case,  the  fix  may  take  long  enough 
to  put  the  whole  ship  at  risk. 

At  least  one  user  command  is  advocating  the  total  reappraisal  of  what 
functions  need  to  remain  afloat  and  what  ones  can  be  brought  ashore 
through  a  transaction  item  reporting  system(Smith,  1991).  Under  this 
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concept,  most  accounting  functions  would  be  moved  ashore.  In  the  shore 
environment,  tasks  could  be  civilianized  and  performed  by  civil  service 
employees  trained  in  accounting.  Even  if  the  jobs  were  still  done  by 
military  personnel,  they  could  be  specifically  trained  and  have 
knowledgeable  coworkers  and  a  telephone  consistently  available. 
Transactions  would  be  reported  via  electronic  means  on  satellite  links.  If 
such  a  change  were  to  be  implemented  it  would  require  basic  changes  in  the 
design  of  the  SMMS  system. 

C.  VIEW  FROM  THE  STEERING  COMMITTEE 

The  shipboard  arena  is  one  of  the  few  Navy  data  processing  areas  that 
remains  under  direct  Navy  control.  Keeping  those  shipboard  systems  viable 
and  maintainable  in  a  rapidly  changing  technological  and  fiscal 
environment  is  the  challenge.  Any  move  that  appears  to  be  wasteful  or 
smacks  of  adding  unnecessary  nice  to  have  items  is  sure  to  bring 
Congressional  criticism  and  possible  funding  cuts.  The  Navy  is  operating 
in  an  environment  where  not  even  the  number  of  type  commanders  is 
guarantied  to  remain  constant  but  decisions  must  be  made  on  continuing 
implementation  of  the  current  two  SNAP  systems  as  well  as  the  pace  and 
upgrading  within  those  systems.  Potential  end  users  vary  from  an  aircraft 
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carrier  with  a  LAN  consisting  of  over  200  units  to  small  ships  with  stand 
alone  PCs. 

D.  YOUR  CHARTER 

To  prepare  for  the  class  discussion,  adopt  the  perspective  of  the  head 
of  the  Navy’s  ADP  steering  committee.  Your  charter  is  to  implement  a 
strategy  to  meet  the  long  term  non-tactical  information  processing 
requirements  of  Naval  afloat  and  ashore  operational  units. 


32 


VI.  TENTATIVE  CONCLUSIONS  AND  RECOMMEl^ATIONS 

A.  CONCLUSIONS 

The  realities  of  the  way  management  information  projects  are 
budgeted,  funded  and  implemented  in  the  Department  of  the  Navy  are 
not  unique.  The  command  structure,  billet  rotation  policies  and 
specialization  of  functional  tasking  do  give  these  processes  characteristics 
that  are  worthy  of  study. 

A  careful  review  and  discussion  of  the  case  study  in  chapter  5 
should  prove  a  fruitful  source  of  potential  pitfalls  that  face  a  large 
organization  trying  to  modernize  its  data  processing  capabilities.  Some 
of  the  pertinent  questions  that  may  be  raised  are: 

•  What  is  the  proper  level  of  authority  to  control  production  and 
integration  of  data  processing  programs? 

•  Is  data  modeling  a  workable  and  worthwhile  activity  and  if  so  at 
what  level  of  the  organization  should  it  be  accomplished? 

•  With  split  responsibility  for  production,  training  and  maintenance  of 
software  can  the  true  return  on  investment  for  updating  and 
integrating  software  be  calculated? 

•  Are  CASE  tools  adequately  developed  to  be  cost  effective  in  the 
Navy  software  development  process? 

•  If  CASE  tools  are  to  be  used  should  contracts  be  written  to  hold 
vendors  accountable  for  successful  transition  from  another  vendors 
product?  And  if  written  would  any  vendor  bid  them? 
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•  Can  a  poorly  prepared  survey  do  more  damage  than  good? 

•  Should  a  CASE  tool  be  utilized  that  generates  code  in  a  proprietary 
language  and  requires  run-time  modules  to  execute? 

B.  RECOMMENDATIONS 

These  recommendations  are  based  on  the  fact  that  the  funding 
environment  within  DOD  is  constrained.  Any  project  must  be  able  to 
prcve  it  is  cost  effective  with  a  relatively  short  payback  period. 

•  If  data  modeling  is  to  be  done,  it  should  be  done  at  the  ship  wide 
level  to  allow  integration  of  ship  wide  requirements.  This  vdll  allow 
immediate  savings  in  reduction  of  support  for  parallel  systems. 

•  New  systems  developed  should  utilize  object  oriented  or  other 
designs  that  allow  enough  flexibility  to  readily  accept  technological 
advances. 


APPENDIX  A 


This  document  is  the  cover  letter  and  edited  four  sections  of  the 
survey  sent  out  by  COMNAVSUPSYSCOM  to  SNAP  users. 
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AUTOVON 


IN  REPLY  REFER  TO: 


0332 

4400 

24  MAY  1991 


From:  Commander,  Naval  Supply  Systems  Command 

To:  Distribution 

Subs:  SUADPS  RELEASE  3  FUNCTIONAL  ASSESSMENT 


Ref:  (a)  Functional  Policy  Council  of  April  1991 


End : 


(1)  Afloat  Business  Systems  Applications 
Comparison 

(2)  Type  Commander  SUADPS  Functional  Evaluation 

(3)  Type  Commander  SUADPS  Functional  Needs  Assessment 

(4)  Type  commander  SUADPS  Reports  Critique 


I.  Pursuant  to  agreements  made  during  the  April  1991  Functional  Policy 
Council,  a  comprehensive  evaluation  of  SUADPS  and  SNAP  II  Supply  and 
Financial  Management  system  strengths  and  weakness  is  underway.  The 
observations  and  recommendations  of  this  study  will  influence  the  manner 
in  which  NAVSUP  will  pursue  the  development  of  the  SNAP  Material 
Management  System  (SMMS) .  To  assist  in  this  evaluation,  a  conprehens i ve 
review  of  applications  now  addressed  by  SUADPS  and  a  needs  assessment  of 
those  applications  not  now  included  in  SUADPS  are  required. 


2.  To  establish  a  baseline  by  which  to  measure  the  effectiveness  of 
our  current  supply  management  systems,  NAVSUP  recently  developed  an 
afloat  business  systems  applications  matrix.  This  matrix  totaled  219 
business  applications  considered  necessary  for  modern  afloat  supply 
operations.  NAVMASSO  compared  current  versions  of  SUADPS,  SFM,  OMMS, 
NALCOMIS  and  ILM  against  this  matrix.  NAVMASSO 's  findings,  enclosure 
(I) ,  are  forwarded  for  information.  NAVSEA  PMS-331  has  tasked  the  MRMS 
development  contractor  to  likewise  compare  MRMS  functionality  against 
the  matrix.  The  results  of  that  comparison  will  be  forwarded  for 
information  under  separate  cover.  Overall,  SUADPS  was  found  to  include 
automated  routines  for  only  109  of  the  219  business  applications. 


3.  To  assess  SUADPS  effectiveness,  a  questionnaire,  enclosure  (2),  is 
forwarded  for  each  business  application  (109)  now  included  in  the 
current  SUADPS  release.  Your  comments  on  each  application  will 
determine  whether  a  function  is  satisfactory  as  designed,  unsatisfactory 
and  in  need  of  redesign,  or  a  candidate  for  pierside  support  or  other 
off -ship  methods. 
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SXibj:  SNAP  II  SUPPLY  AND  FINANCIAL  MANAGEMENT  SYSTEM  FUNCTIONAL 
ASSESSMENT 


4.  For  each  application  not  now  automated  in  SFM  5.10  (122),  a 
questionnaire,  enclosure  (3),  is  also  included.  Your  comments  will 
influence  whether  this  application  will  be  automated  in  SMMS. 

5.  Finally,  your  assistance  is  requested  to  evaluate  the  appropriateness  of 
the  reports  now  included  in  SUADPS.  Your  comments  on  enclosure  (4)  will 
influence  whether  these  reports  will  be  continued  under  SMMS,  should  be 
repositioned  to  a  PC  MIS  environment,  or  dropped  from  use. 

6.  Completing  enclosures  (2),  (3)  and  (4)  will  require  a  thorough  insight 
into  he  strengths  and  weaknesses  of  SNAP  II  SFM  and  a  comprehensive 
understanding  of  how  afloat  supply  officers  and  staffs  now  manage  their 
affairs  with  the  help  of,  and  some  times  in  spite  of,  our  afloat  business 
information  management  systems.  Fleet  support  of  this  functional  assessment 
is  necessary  to  ensure  that  SMMS  addresses  our  mutual  needs  and  desires  and 
concentrates  on  delivering  the  greatest  benefit  for  our  investment. 

7.  It  is  requested  that  enclosures  (2),  (3)  and  (4)  be  completed  and 
returned  to  NAVSUP  0332  by  15  July  1991. 


S.  W.  Baldwin 
Acting 

Assistant  Commander 
Inventory  &  Systems  Integrity 


Distribution: 
COMSUBLANT  (NS) 
COMSUBPAC  (N5) 
COMNAVSURFLANT  (N7) 
COMNAVSURFPAC  (N7 ) 

Copy  to:  (w/o  ends) 
CINCLANTFLT  (N4) 
CINCPACFLT  (N4) 
NAVMASSO  (01) 

NAVSEA  (04-TD) 

NSCS  Athens  (48) 
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Enclosure (1) 


Page  No. 

05/24/91 

APPLICATIONS  FOUND  IN  VARIOUS  AFLOAT  BUSINESS  SYSTEMS 


APPLICATION  SUADPS  SFM  OMMS  NALCOMIS  ILM 


**  BUSINESS  FUNCTION:  ALLOWANCE /TECH  DATA 


*  SUB  FUNCTION:  CONFIGURATION  MGMT 
BASELINE 

CONFIGURATION  CHANGES 


N  N  Y  Y 

N  N  Y  Y 


*  SUB  FUNCTION:  TECHNICAL  DATA 
TECH  MANUALS 

COMPONENT  CHARACTERISTICS 


N  N  Y  Y 

N  N  Y  N 


*  SUB  FUNCTION:  ALLOWANCE 
APL  QA 

COMPUTATION  REVIEW 
FCFBR 

RANGE/DEPTH  ANALYSIS 
LOAD  LIST  EFFECTIVENESS 


P  N  Y  N 

Y  N  N  Y 

N  N  N  N 

Y  Y  N  Y 

Y  N  N  N 


*  SUB  FUNCTION:  ILO/DECK  LOAD 
CHANGE  IN-FORCE  STRUCTURE 
REPAIR  PARTS  ANALYSIS 
CONFIGURATION  ANALYSIS 
TECHNICAL  DOCUMENTATION 
ANALYSIS 

LOAD  LIST  ANALYSIS 
LOGISTICS  READINESS 
2M  SUPPORT 


SUPPORT 

N  N  N  N 
N  N  N  N 
N  N  N  N 
N  N  N  N 

N  N  N  N 
N  N  N  N 
N  Y  N  N 
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Page  No .  2 

05/24/91 

APPLICATIONS  FOUND  IN  VARIOUS  AFLOAT  BUSINESS  SYSTEMS 


APPLICATION  CATEGORY  SUADPS  SFM  OMMS  NALCOMIS  ILM 


**  BUSINESS  FUNCTION:  BUSINESS  OPERATIONS 


*  SUB  FUNCTION:  MATERIAL  REQUESTS 


ACCEPT  CUSTOMER  MATERIAL 
REQUESTS 

Y 

Y 

N 

Y 

Y 

EDIT  MATERIAL  REQUESTS 

Y 

Y 

N 

Y 

Y 

PROCESS  REQUIREMENTS  FOR 

ISSUE /REFERRAL 

Y 

Y 

N 

Y 

Y 

MONITOR  REQUISITION  STATUS 

Y 

Y 

N 

Y 

Y 

MODIFY,  CANCEL,  FOLLOW-UP 
REQUISITIONS 

Y 

Y 

N 

Y 

Y 

NON-STANDARD  MATERIAL  REQUESTS 

P 

Y 

N 

N 

N 

RESCREEN 

P 

N 

N 

Y 

N 

CANNIBALIZATIONS / PAYBACKS 

N 

N 

N 

Y 

N 

UNREP  PLANNING 

Y 

N 

N 

N 

N 

SERVICE  REQUESTS 

Y 

Y 

N 

N 

N 

*  SUB  FUNCTION:  DLR  MANAGEMENT 

CARCASS  TRACKING 

Y 

Y 

N 

Y 

N 

2M  CHECKS /CERTIFICATION 

N 

N 

N 

Y 

N 

*  SUB  FUNCTION:  EXPENDITURES 

MATERIAL  DISPOSITION 

DEFICIENT 

MATERIAL 

Y 

Y 

N 

Y 

Y 

MATERIAL  DISPOSITION 

HAZ  WASTE 

N 

N 

N 

P 

N 

MATERIAL  DISPOSITION 

EXCESS 

Y 

Y 

N 

Y 

Y 

SCRAP 

N 

N 

N 

N 

N 

SURVEY  PROCESSING 

Y 

Y 

N 

N 

N 

ROD  PROCESSING 

N 

N 

N 

N 

N 

QDR  PROCESSING 

N 

N 

N 

Y 

N 

TDR  PROCESSING 

N 

N 

N 

Y 

N 

*  SUB  FUNCTION:  EXPEDITING 

ID  HOT  REQUISITIONS 

N 

Y 

N 

Y 

Y 

ON-LINE  MANAGEMENT 

Y 

Y 

Y 

Y 

Y 

HOT  REPORTS 

CASREP 

N 

Y 

N 

N 

N 

HOT  REPORTS 

NMCS/PMCS 

N 

Y 

N 

Y 

N 

HOT  REPORTS 

AWP 

N 

N 

Y 

Y 

N 

HOT  REPORTS 

WORK  STOPPAGE 

N 

N 

N 

Y 

N 

HOT  REPORTS 

HOT  JCN 

N 

Y 

N 

YN 

HOT  REPORTS 

SPECIAL 

PROJECTS 

N 

Y 

N 

Y 

N 

SUB  FUNCTION:  MOV 

EXTERNAL  ICP  MOV  PROCESSING 

Y 

Y 

N 

N 

N 

INTERNAL  MOV  PROCESSING 

Y 

Y 

N 

N 

N 
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Page  No .  3 

05/24/91 

APPLICATIONS  FOUND  IN  VARIOUS  AFLOAT  BUSINESS  SYSTEMS 
APPLICATION  CATEGORY  SUADPS  SFM  OMMS  NALCOMIS  ILM 


**  BUSINESS  FUNCTION:  CONTROL 

*  SUB  FUNCTION:  CONSTANTS 
SYSTEM  CONSTANTS 
VALIDATION  TABLES 
LOCAL  CONSTANTS 
COUNTERS 

*  SUB  FUNCTION:  SECURITY 
USER  ACCESS 
MAN  HOUR  ACCOUNTING 
MAN  HOUR  DATA  PER  TRANSACTION 

*  SUB  FUNCTION:  ADP  OPERATIONS 
BACK /UP 
RECOVERY 
ADP  SCHEDULING 

SYSTEM  CONFIGURATION  MODULE 

MANAGEMENT 

SUB  FUNCTION:  TRANSACTION  RECORDING 

PURGE  TO  HISTORY  Y  Y  N  P 

CTL  PROCESSING  Y  P  N  N 


Y  Y  N  Y 

Y  Y  N  Y 

Y  Y  N  N 

Y  Y  N  N 


Y  Y  N  N 

Y  Y  N  Y 

Y  Y  N  N 

Y  Y  N  N 


Y  Y  N  Y 

N  N  N  N 

N  N  N  N 
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Page  No ,  4 

05/24/91 

APPLICATIONS  FOUND  IN  VARIOUS  AFLOAT  BUSINESS  SYSTEMS 
APPLICATION  CATEGORY  SUADPS  SFM  OMMS  NALCOMIS  ILM 


**  BUSINESS  FUNCTION:  EXTERNAL  INTER  ACES 


*  SUB  FUNCTION:  ON-LINE  INTERFACES 


NALCOMIS 

Y 

N  N 

Y 

OMMS 

Y 

Y  Y 

N 

MRMS 

Y 

N  N 

N 

IMMS 

Y 

N  N 

N 

UADPS 

N 

N  N 

Y 

UICP 

N 

N  N 

N 

SCLSIS 

N 

N  Y 

N 

APADE 

N 

N  N 

N 

DEPRA 

N 

N  N 

N 

DDN 

N 

N  N 

Y 

PCMT 

N 

N  N 

N 

ASCC 

N 

N  N 

Y 

ADM 

N 

Y  N 

N 

MSDS 

N 

Y  N 

N 

SAMS 

N 

Y  N 

N 

SPLICE 

N 

N  N 

N 

*  SUB  FUNCTION:  BATCH  INPUTS  FROM 

CHANGE  NOTICE 

Y 

N  Y 

Y 

ASI 

P 

Y  Y 

N 

COSAL 

Y 

N  Y 

N 

AVCAL 

Y 

N  N 

Y 

TARSLL 

Y 

N  N 

N 

FILL 

Y 

N  N 

N 

FAADC  TAPES  SFOEDL 

N 

N  N 

N 

FAADC  TAPES  C&H 

Y 

N  N 

N 

FAADC  TAPES  OTHER 

N 

N  N 

N 

RRTMIS 

N 

N  N 

N 

E38 

Y 

N  N 

Y 

ICP  DEMAND 

N 

N  N 

N 

CYCLIC  ASSET 

N 

N  N 

N 

*  SUB  FUNCTION:  BATCH  INPUTS  TO 

RRIMIS 

Y 

N  N 

N 

CYCLIS  ASSET 

Y 

N  N 

N 

PMO 

Y 

N  N 

N 

PARENT  TENDER 

Y 

N  N 

N 

*  SUB  FUNCTION:  BATCH  INPUTS  TO/FROM 

SNAP  II 

Y 

P  N 

N 

SUB  FUNCTION:  ON-LINE  INTERFACES 

SUADPS 

Y 

N  N 

Y 
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Page  No .  5 

05/24/91 

APPLICATIONS  FOUND  IN  V  lOUS  AFLOAT  BUSINESS  SYSTEMS 


APPLICATION  CATEGORY  SUADPS  SFM  OMMS  NALCOMIS  ILM 


**  BUSINESS  FUNCTION:  FINANCIAL 


*  SUB  FUNCTION:  OM,N 

SHIP'S  GRANT  ACCOMMODATION  Y 
DEPARTMENTAL  BUDGET  MANAGEMENT  Y 
SHORE  LIST  PROCESSING  SFOEDL/AUOL  P 
TRANSMITTALS  ASHORE  BOR/TL  Y 
PROJECT  ACCOUNTING  N 
BUDGET  FORECASTING  N 
BUDGET  EXECUTION  GRAPHICS  N 
REPORT  OF  CREDITS  Y 
ROV  AVAILABILITY  COST  REPORT  Y 
FLIGHT  HOUR  ACCOUNTING  P 


Y  N  N 

Y  N  N 

Y  N  N 

Y  N  N 

N  N  N 

P  N  N 

N  N  N 

N  N  N 

N  N  N 

N  N  N 


*  SUB  FUNCTION:  NAVY  STOCK  FUND 
TRANSMITTAL  OF  NSF  DETAIL 
ASHORE 

FAADC  RECONCILIATION  DATA 

PROCESSING 

SAC  224  PROCESSING 


Y  N  N  N 

Y  Y  N  N 

N  N  N  N 


*  SUB  FUNCTION:  OTHER  ACCOUNTING 

OPN  ACCOUNTING 

SCN  ACCOUNTING 

TOB  ACCOUNTING 

SHIP'S  STORE  ACCOUNTING 


N  Y  N  N 

N  N  N  N 

N  N  N  N 

N  N  N  N 
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Page  No .  6 

05/24/91 

APPLICATIONS  FOUND  IN  VARIOUS  AFLOAT  BUSINESS  SYSTEMS 


APPLICATION  CATEGORY  SUADPS  SFM  OMMS  NALCOMIS  ILM 


**  BUSINESS  FUNCTION:  I -LEVEL  MAINT  SUPPORT 


*  SUB  FUNCTION:  COMPONENT  CONTROL 

INDUCTIONS 

REPAIR  AND  RETURN 

CANNI BALI ZATIONS / PAYBACKS 

CONDITION  CODE  TRANSFERS 

El  MANAGEMENT 

RFI  RETURN 

NRFI  RETURN 

FLR  MANAGEMENT 

2M  MANAGEMENT 

AWP  MANAGEMENT 

MAINTENANCE  ACTION  REPORTING 


N  N  N 

P  ■  N  N 

N  N  N 

N  N  N 

N  N  N 

Y  N  N 

Y  Y  N 

P  Y  N 

N  Y  N 

N  N  N 

Y  N  N 


Y  N 

Y  N 

Y  N 

N  N 

Y  N 

Y  N 

Y  N 

Y  N 

N  N 

Y  N 

Y  N 
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Page  No .  7 

05/24/91 

APPLICATIONS  FOUND  IN  VARIOUS  AFLOAT  BUSINESS  SYSTEMS 


APPLICATION  CATEGORY  SUADPS 

SFM 

OMMS 

NALCOMIS  ILM 

**  BUSINESS  FUNCTION:  INVENTORY 

*  SUB  FUNCTION:  MAINTAIN  DATA 
UPDATE  MANAGEMENT  DATA 

Y 

Y 

Y 

Y 

MAINTAIN  INVENTORY  BALANCE  BY 

N 

Y 

N 

N 

LOCATION 

MAINTAIN  INVENTORY  BY  OTHER 

BY  LOT 

N 

N 

N 

N 

VARIABLES 

MAINTAIN  INVENTORY  BY  OTHER 

CONTRACT 

N 

N 

N 

Y 

VARIABLES 

NUMBER 

MAINTAIN  INVENTORY  BY  OTHER 

SHELF  LIFE 

N 

Y 

N 

N 

VARIABLES 

EXPIRATION 

*  SUB  FUNCTION:  MANAGE  STOCK  LISTS 

DEMAND  HISTORY  COLLECTION 

Y 

Y 

N 

P 

LEVEL  SETTING 

Y 

Y 

N 

N 

REPLENISH 

Y 

Y 

N 

Y 

EXCESS  MANAGEMENT 

Y 

Y 

N 

N 

*  SUB  FUNCTION:  VALIDITY  FUNCTIONS 

PHYSICAL  INVENTORY 

Y 

Y 

N 

Y 

RECONCILIATION 

P 

Y 

Y 

CAUSATIVE  RESEARCH 

P 

N 

N 

Y 

ADJUSTMENTS 

Y 

Y 

N 

N. 

*  SUB  FUNCTION:  SPECIAL  INVENTORIES 

SEAMART 

P 

N 

N 

N 

FUEL 

P 

N 

N 

N 

SHELF  LIFE  MATERIAL 

Y 

Y 

N 

N 

SUSPENDED  MATERIAL 

N 

Y 

N 

Y 

GAS  AND  CYLINDERS 

P 

Y 

N 

N 

HAZMAT 

P 

Y 

N 

N 

Q  COSAL  MATERIAL 

y 

Y 

N 

N 

DLRS 

Y 

Y 

N 

Y 

LEVEL  I /SUBSAFE 

P 

N 

N 

N 

NUKE  WATER  CHEMICALS 

P 

N 

N 

N 

AMMUNITION 

N 

N 

N 

N 

LOCAL  ROTABLE  POOL  ASSETS 

N 

N 

N 

Y 

EQUIPAGE 

MHE 

N 

N 

N 

N 

EQUIPAGE  CONTROLLED 

EQUIPAGE 

N 

Y 

N 

N 

EQUIPAGE  OTHER 

CRITICAL 

N 

Y 

N 

N 

MAMS 

N 

Y 

N 

N 

OSI/RSS 

N 

Y 

N 

N 

GPETE/SPETE  CALIBRATION 

LAB 

N 

Y 

N 

P 

PROVISIONS 

y 

N 

N 

N 

SHIPS  STORE  IQ  COG  MATERIAL 

y 

Y 

N 

N 

PRE- EXPENDED  BIN  MATERIAL 

Y 

N 

N 

Y 

OUTBOUND  BACKUP 

Y 

N 

N 

Y 

INBOUND  BACKUP 

Y 

N 

N 

Y 
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STRATEGIC  WEAPONS  MATERIAL 
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APPLICATIONS  FOUND  IN  VARIOUS  AFLOAT  BUSINESS  SYSTEMS 
APPLICATION  CATEGORY  SUADPS  SFM  OMMS  NALCOMIS  ILM 


**  BUSINESS  FUNCTION:  PERFORMANCE  MONITORING 


*  SUB  FUNCTION:  INVENTORY 
DEMAND  EFFECTIVENESS 
ALLOWANCE  EFFECTIVENESS 
UMMIPS  PERFORMANCE 
RANGE /DEPTH  ACCURACY 
INVENTORY  ACCURACY 
CAUSATIVE  RESEARCH  RESULTS 


Y 

Y 

Y 

Y 

Y 
N 


Y  N  P 

Y  N  Y 

N  N  P 

Y  N  Y 

Y  N  N 

N  N  N 


*  SUB  FUNCTION:  FINANCIAL 
NSF  STATUS 
BUDGET  EXECUTION 
ADJUSTMENT  MEASUREMENT 


P  Y  N  N 

N  Y  N  N 

N  Y  N  N 


*  SUB  FUNCTION:  WORKLOAD 
ACTION  PROCESS  TIME 
AVG  CUSTOMER  WAIT  TIME 
EXCEPTION  MEASUREMENT 
ENDURANCE 
PERSONAL  WORKLOAD 
PERSONAL  PRODUCTIVITY 
QA  PROGRAM 


N 

N 

N 

N 

N 

N 

N 


N  N  Y 

N  N  Y 

N  N  N 

N  N  N 

N  N  N 

N  N  N 

N  N  N 


SUB  FUNCTION:  PHYSICAL  DISTRIBUTION 
RRTMIS  N 

PROCESS  CONTROL  N 


N  N  N 

N  N  N 
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APPLICATIONS  FOUND  IN  VARIOUS  AFLOAT  BUSINESS  SYSTEMS 


APPLICATION  CATEGORY  SUADPS  SFM  OMMS  NALCOMIS  ILM 


**  BUSINESS  FUNCTION:  PHYSICAL  DISTRIBUTION 


*  SUB  FUNCTION:  INBOUND  MATERIAL 


RECEIPT  IN  PROCESS 

Y 

Y 

N 

Y 

Y 

CHARACTERISTICS 

RECEIPT  IN  PROCESS 

LOT  SIZE 

N 

N 

N 

N 

Y 

CHARACTERISTICS 

RECEIPT  IN  PROCESS 

CONT  CT 

N 

N 

N 

Y 

Y 

CHARACTERISTICS 

RECEIPT  IN  PROCESS 

NUMBER 

PACK  ATE 

N 

N 

N 

N 

Y 

CHARACTERISTICS 

RECEIPT  IN  PROCESS 

SHELF  LIFE 

N 

N 

N 

N 

Y 

CHARACTERISTICS 

RECEIPT  IN  PROCESS 

N 

N 

N 

N 

Y 

CHARACTERISTICS 

RECEIPT  IN  PROCESS 

CUBE 

N 

N 

N 

N 

Y 

CHARACTERISTICS 

RECEIPT  IN  PROCESS 

DESTINATION 

N 

Y 

N 

N 

N 

CHARACTERISTICS 

STAGING  FOR  TURNOVER 

N 

Y 

N 

N 

N 

STAGING  FOR  STOW 

N 

Y 

N 

N 

Y 

STOW 

CLEAN 

N 

Y 

N 

N 

Y 

STOW 

N 

y 

N 

N 

N 

PROOF  OF  DELIVERY 

N 

Y 

N 

Y 

N 

*  SUB  FUNCTION:  STOREROOM  MGMT 
STOWAGE  PLAN 

N 

N 

N 

N 

N 

LOCATION  CHARACTERISTICS 

SIZE 

N 

Y 

N 

N 

N 

LOCATION  CHARACTERISTICS 

SECURITY 

N 

N 

N 

N 

N 

LOCATION  CHARACTERISTICS 

WEIGH  LIMITS 

N 

N 

N 

N 

N 

LOCATION  CHARACTERISTICS 

CUBE  LIMITS 

N 

N 

N 

N 

N 

LOCATION  CHARACTERISTICS 

TYPE  MATERIAL 

N 

Y 

N 

N 

N 

LOCATION  CHARACTERISTICS 

MATL 

N 

Y 

N 

N 

N 

RESTOWAGE 

COMPATIBILITY 

N 

y 

N 

N 

N 

LABELLING 

MATERIAL  INFO 

Y 

Y 

N 

N 

Y 

LABELLING 

STOW  CATION 

Y 

Y 

N 

N 

Y 
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APPLICATIONS  FOUND  IN  VARIOUS  AFLOAT  BUSINESS  SYSTEMS 


APPLICATION 

SUADPS  SFM 

OMMS 

NALCOMIS 

ILM 

*  SUB  FUNCTION:  OUTBOUND  MATERIAL 

PICK 

Y 

N 

N 

Y 

N 

STAGE 

P 

N 

N 

N 

N 

PREPARE  DOCUMENTATION 

Y 

N 

N 

Y 

N 

PACK /CRATE 

N 

N 

N 

N 

N 

RETROGRADE  HANDLING 

Y 

N 

N 

Y 

N 

PROOF  OF  SHIPMENT 

N 

Y 

N 

N 

N 

TRANSHIPMENTS 

N 

Y 

N 

N 

N 

ENGINEERING  INVESTIGATIONS 

N 

N 

N 

Y 

N 

TURN- INS 

MTIS 

Y 

Y 

N 

Y 

Y 

TURN- INS 

SUPPLY 

CENTER  Y 

y 

N 

N 

Y 

TURN- INS 

DRMO 

Y 

Y 

N 

N 

N 

TURN- INS 

DLRS 

Y 

Y 

N 

Y 

N 

*  SUB  FUNCTION:  PLANNING 
WORKLOAD  SCHEDULING 
PHYSICAL  CONSTRAINTS 
T-SHED  BACKLOAD  MANAGEMENT 
UNREP  PLANNING 
UNREP  PLANNING 
UNREP  PLANNING 
UNREP  PLANNING 


'  48 


p 

N 

N 


PROVISIONS  Y 
BULK  Y 
BIN  Y 
TURNOVER  Y 


N  Y  Y  N 

N  N  N  N 

N  N  N  N 

N  N  N  N 

N  N  N  N 

N  N  N  N 

N  N  N  N 


Enclosure  (2) 

TYPE  COMMANDER  SUADPS  FUNCTIONAL  EVALUATION 


BUSINESS  FUNCTION: 
SUB  FUNCTION: 
APPLICATION: 
CATEGORY : 


90  sheets  total 
one  for  each 
y  under  SUADPS 
in  enclosure  (1) 


EVALUATOR: 


COMMAND /CODE / TELEPHONE : 


l.a.  Is  this  application  necessary?  1  2 

1. b.  If  2,  3,  4,  why?  (rank  in  order  of  importance:  A,  B,  C,  D) 

Needed  for  supply  officer  or  staff  decision  making:  _ 

Needed  for  customer  decision  making  or  information:  _ 

Needed  for  internal  process  control:  _ 

Needed  for  external  reporting:  _ 

Needed  for  internal  higher  management  reporting:  _ 

2.  Is  this  application  easy  to  use?  1  2 

3.  Do  operators  have  to  "trick"  the  system  to  get  this 

application  to  work?  If  2,  3,  or  4  explain:  1  2 


YES 
3  4 


3  4 


3  4 


Is  OJT  sufficient  training  for  operators  to  become 
proficient  in  the  use  of  this  application?  1 

Is  "Shiprider"  assistance  necessary  to  successfully 
use  this  application?  1 

Are  clear  instructions  available  on  how  to  use  this 
application?  1 

Do  problems  frequently  occur  using  this  application? 
If  2,  3,  or  4,  explain:  1 


3  4 


3  4 


3  4 


3  4 


7.  Does  this  application  provide  sufficient  1234 

information?  If  1,  2,  or  3 ,  explain  what  is  missing. 


Should  this  business  application  be  done  ashore?  1 
If  3  or  4,  explain  how: 


3  4 


What  improvements  would  you  suggest  for  any  aspect  1 
of  this  application? 


3  4 
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Enclosure  (3) 

TYPE  COMMANDER  SUADPS  FUNCTIONAL  NEEDS  ASSESSMENT 


BUSINESS  FUNCTION: 
SUB  FUNCTION: 
APPLICATION: 
CATEGORY: 

EVALUATOR:  _ 


108  sheets  total 
one  for  each 
N  under  SUADPS 
in  enclosure  (1) 


COMMAND /CODE/TELEPHONE : 


THIS  APPLICATION  IS  NOT  IN  SUADPS  BUT  MAY  BE  PLANNED  FOR  A 
LATER  RELEASE  PLEASE  ANSWER  THE  FOLLOWING  QUESTIONS: 

NO  YES 

l.a.  Should  this  application  be  automated  in  SUADPS?  1234 

1. b.  If  2,  3,  4,  why?  (rank  in  order  of  importance:  A,  B,  C,  D) 

Needed  for  supply  officer  or  staff  decision  making:  _ 

Needed  for  customer  decision  making  or  information:  _ 

Needed  for  internal  process  control:  _ 

Needed  for  external  reporting:  _ 

Needed  for  internal  higher  management  reporting:  _ 

2,  What  information  should  this  application  provide? 


3.  In  what  form  should  the  information  be  provided? 


4.  Is  this  application  now  performed  manually?  1234 

4. a.  If  3  or  4,  what  skill  level  is  needed  to  accomplish 
the  task? 


Officer 

CPO 

LPO 

PO 

SN 

4  .  b .  I  f  3  or 

4 ,  how  often 

is  this  application  accomplished? 

Deployed: 

Annually 

Monthly 

Weekly 

Daily 

In  home  port : 
Annually 

Monthly 

Weekly 

Daily 

During  Availabilities: 
Annually  Monthly 

Weekly 

Daily 

5.  Has  this  application  been  automated  with  the  use  of  locally 
developed  software? 
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3JKR  vsmxmrr  isKEis  pmjEis 


ISSUE  FENUINS  HIE  (PEKKT  2) 

008  Sfm>/SHj 

008  S»MVSKL  1  TmL  IZniOL 

006  2  \AI1£  £V  AT  GCCE 

008  SA^MV^  3  lEIML  KEICKr 

008  S»f«\/SAL  4  AEA  POn'  CF  SAL  CEIAIL 

008  s»f ^SAL  5  mmKR[  Mmsmir 

009  OQ5AL  AHi  At^OESIS  (UEID  C  &  H) 

009  CQ6AL  tfSCEUnCE  (USJD  A,  B,  T) 

009  OBAL  FEPCENITCE  (U5ID  C  M) 

009  AJCAL  KLC  fmJiSJS 

009  f!JCA[jmcEinxs: 

OU  }AS1£H  STOCK  smius 

015  QPEAR  mSICRf  FEE  HOCESSHC  JEKRT 

036  IS5LES  CF  OCNOOIfD  IKC  SUBSTMCES 

044  RO  CE}«NDFEKKr 

051  DCESSIVE  KX3£ncrB  USEDG 

051  KXAUCN  AUDIT  IISTDC 

051  JKEL-  CN  HM®  -  ND  IDCKdCN 

051  MAQHIAL  -  lERKEOE  ICXAEICK  LESIDC 

051  QCBNITiy  WIEKnCN  (BOT  CNE) 

051  QffiNmy  WEKnCN  (ERKT  TWO) 

054  Dm  FRINr  FEKPT 


IKE  OXES:  FE  F!EgnFBD  DOEFNAL  FPEQUEJC^  CEDES:  D  DAXL^  W  WEEKLY 

RI  WJIFED  INURWL  M  FENIHiy  Q  OLftRUFELY 

IM  INISHftL  I®NW2MENr  Y  YEARLY  A  AS  FBJJIKED 
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SUAIX5  ^ONK2MEN^  FCPCRIS  AN70SIS 


\ 


lyOCM: _ 

ni  FWd’JTH' 


ESSVUJKICR: 
ISPCRT  FUUL  NMIE 


tfiOESiM.  CBLEcancN  cpmn  i 

MOERIAL  CB[1GKCK2I  \ALIEKnai  CPTICN  2 
mrEROL  OBUiGKnCN  ^ALEDKnCN  CFTDK  3 

wanoKL  OELHsaicti  viazixnat  cptku  a 

MKQKIAL  CBLIiSaiCN  VKLintirrON  CPTLCtf  5 

ufasoKL  CRTirmcw  \MJiiiKnrK  cfucn  6 

maSKOL  cmCKTICN  VKLUmCN  CPnCN  7 
CEMMID  FEKRTOG 

IXPCfT  LEVEL  REHOKTffiUS  TKACKQG 

aSGSUCAOED  EACKIP  USEDC 

PEO^  FESPONSE  TIME  MIS 

UtGES  inUFCRMKE  FEECKT 

OLARIERiy  i^SSET  KEPCRT 

•nCTMEEICRr 

EXDEMCED  HUE^  \AIUE  CF  DIO  KEQUISmaC 
DIO  OES  WISH  ^VOIXaMi  CM 
mavaic  kziohp  pmv  kr  reib^se 


w 

OXE 


lEMAM)  Hisiav  HCCESSGDG  FEPCET 

amJD  •IME  (IJE-UNE 

MASTER  SKX3C  SI7£IL5  AND  liXT^KR  LESIHG 

CEFIOAD  EXIEICED  MIEY  VAILE 

IMVEMKFY  IRDGRESS  FEECRT 

lOIEMriAL  GAII6  ;a3}  IOGSES  Bjf  INVENICFCf 

aiF  FBXFD  rFTFTnP 

REODISmCN  HUNIOTr 


IBE  GGQES:  PEJJUFSD  EXTERNAL  FRECUENCY  CDCES:  D  DMIY  W  WEEKY 

RI  RECUIFED  INIEFNAL  M  ECNIHIY  Q  QUAFOERIY 

IM  IftN'CEMENT  Y  YEARLY  A  AS  FBJJIRED 
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SUACE5  I«I«^9EMBh7r  REFORIS  M«^USIS 


TYCCM; 

m  nwcaicir 


_  EVMIMCR: 

UPCFT  FULLNNC 


091  SURFMZ  MMNIBmi:  DK 

093  <SajP  CMXHIXnCN  JSOJESI 

094  ISCEZFT  IN  SCGSESS 

096  AvixncN  iKonsmt:!!  ekia  wicKmc 

100  aiMttCEiNG  cfTiaR's  Ecmr  (rerkt  21) 

100  CEB«iiiENr  Euaxr  (fekkt  21) 

100  mvcsiai  EUDGET  (EEZCCT21) 

100  INVENICEV  JUlTUEriMENr 

100  REKRT  03  FlUftNCIfiL  DWENICIV  HEKKT 

100  REPCRT  04  JCNIHC^  KUTTW  FEPCKT 

100  REKKT  04  MlTIHLy  mUPIS  FEKKT 

100  KEKFT  05  ICNlHLy  TO  DISPDSftL 

100  raKRT  05  OK)  'IRNCFIR 

100  KEPCRT  06  NC  2074  OKRSS 

100  FEPCKT  07/08  imX34E7  176  KV  A&B  SU4 

100  FEPCKT  09  WmiST  RPM  2051 

100  FEPCKT  10  SUFH;^  EFFECTIVENESS  FEPCKT 

100  FEPCKT  20  IKFIIIID  CPEER  SMWCi 

100  FEPCKT  22  (MIO^/EKFENLED  DEIEEFENCES 

100  FEPCKT  23  HRICR  FISCAL  YE3«  IPMCWZCICN 

100  FEPCKT  24  MSS  FEPCKT  CF  CFEEinS 

100  FEPCKT  26  FUGHT  CPS  BUDGET  OKIAR 

100  FEPCKT  28  AFM  BCCGET  CFIAR 

100  FEPCKT  34  INVENICFY  ACOIBIMENT  FEPCKT 

100  FEPCKT  41  SUFPCKT  UNITS  BCR 


- CEE — 

OXE 

CFUm 

^OTE" 

THIGH) 

OODE 

ocmi] 

(lOW) 

IBE  CDCES:  FE  FEQUIFED  EXEEFNRL  FFEQUENCy  OXES:  D  OMDf  W  WEEKLY 

FI  FEPUIFED  INIEimi  M  JCNIHiy  Q  QCMOEE^y 

IM  3M®^RL  FWWZMENT  Y  YEARLY  A  AS  FEQUIFED 
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g  I  g  O  3  I  8  i  §  P  P  P  e  S  g 


SUMK  MftNfCaiENr  FEPCKIS  ANAKSIS 


TKEM: _ 

m  TiJtiCSTST 


_  EVMIMCR: 

TEPCRT  FULL  N?»E; 


TEE  FRgpRY 
occE  cfih: 
axE 


100  REKRT  42  FEDCLFSABLE  BUDGET  OPTAR 
100  FEKRT  46  TOJ  KJKJUmJTi  COST  FSCRT 

100  FEKRT  47  SUFFLEES  M4D  EQUIEMZ  B3^ 

100  FEKRT  49  USID  B  i9<D  T 

100  SM:  207  FEKRES 

100  STOCK  ASSET  DCXIAR  \AIUE  DOEFETON 

100  FIHD  CEmVDSENDilK; 

100  SUFKEOED  IKHS  KR  VEG 

FIXED  AIICWWCE  JftNAIMENT  FEVHW  FEKRT 
OM  KHLElFf  FOE  HCCESSIIC  FEKRT 
FINMOAL  IPAieACCrCN  lEDSER 
MAOEPIAL  IRMGACriCM  FEKRT 
QOGGAL  IRNEACEKN  FEPCRT 
FEQUISmCN  TRANSACnCN  IILSR 
KXARlS/KEEnrK  Its  FEKRT 
MASTER  \AIZDmCN  TABLE  HONIO^ 
OMJIAITVE  CeO  FUE  HCCESSnC  FEKRT 
CRDER  AND  SHIP  TIME  ANAIXSIS 
BKICH  FECEIPr 

on  ngCAL  YR  TO  nKTF.  BFn-.’rPT  TTSmC 
SU5FENLED  TRAISA:nCN 
SLMftFTZATECN  OF  DNHJIKRIZED  CN  CFEER 
CANCEUED  STOCK  HEMS  CWER  30  DKB 
CMTOTKIFS  KR  FAFTIAI/FUIL  CMIGELIAnCN 


LEE  OXEB:  IE  FBjOlIED  EXII3?«L  IREQUENCY  CDCES;  D  EMIir  W  WEEKLY 

F[C  FEgmED  INIER^  M  URDUY  Q  CJftRURIY 

m  miEFm.  m9££MEUT  y  yearly  a  as  feoubed 
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SLJACF5  mmsmrr  jefcris  analysis 


OMEX  IH«IX»ED  opnas  C,  H  MC  J 

INCC  INVOOIED  DSXNIiriUES 

\JMEX.  INffiiaSD  DOminUFE  Ain 

INCX  UMEX  mXSSSSG 

onmy  wo  ORtfBFBR  keeckt 

UnLEK  ISSUE  mCfllG  ni£  (RtKKT  3) 

X43  SJRfEi  PEFORT 

X43  QOOSAL  SlIWEY  FEKRT 

X49  IMNIMNDG  CUFRENCX  OF  AHTOHOKmC 

X49  0A3A 

5B4  KnsmAL  GAIH/KBS  nCM  SCHED  INVE^^ 

XB4  BNICH  ERCE  KEKKT 

2X  RElSnsmOG  ISOJIKOC  I£XXL  ERXIFEMENT 

20C  TRAICSOICN5  ISI£2££D  TO  E^fCNT  TENTER 

ZOC  TRAfSTOiaE  PEIDASED  FPCM  SUHTX 


USE  GOCES:  FE  KEUJIWD  EXURWL  FFEQUENCX  COCES:  D  EAIIX  W  WEEKLY 

FI  REQUIFE3  INIEFNAL  M  fCNIHLY  Q  GLRRIEFIY 

3M  JWWGEMENT  Y  YEARLY  A  AS  FEJ3JIRED 
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APPENDIX  B 

This  dociiinent  is  a  collection  of  the  cover  letters  sent  in 
response  to  survey  in  appendix  A. 
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DEPARTMENT  OF  THE  NAVY 
COMMANDER  SUBMARINE  FORCE 
U  S  ATLANTIC  FLEET 
NORFOLK  VIRGINIA  23511-5230 


4400 

Ser 

N514/6 

374 

08  JUL 
1991 


From;  Commander  Submarine  Force,  U.S.  Atlantic  Fleet 

To:  Commander,  Naval  Supply  Systems  Command  (Code  0332) 

Subj:  SNAP  II  SUPPLY  AND  FINANCIAL  MANAGEMENT  SYSTEM 

FUNCTIONAL 

ASSESSMENT 

Ref:  (a)  Commander,  Naval  Supply  Systems  4400  Ser  0332  of 

24  May  1991 

End:  (1)  Type  Commander  SNAP  II  SFM  Functional  Evaluation 

(2)  Type  Commander  SNAP  II  SFM  Functional  Needs 
Assessment 

(3)  Type  Commander  SNAP  II  SFM  Reports  Critique 

1.  In  response  to  reference  (a),  enclosures  (1)  through  (3)  are 
forwarded.  Some  of  the  forms  in  the  enclosures  were  left  blank  due  to 
the  ambiguous  nature  of  the  application  or  sub-function  description.  We 
would  be  happy  to  comment  if  the  ambiguities  can  be  clarified. 

2.  Our  position  remains  that  of  supporting  and  improving  the  current 
SNAP  II  software  found  in  SFM,  as  well  as  the  Maintenance  Data  Subsystem 
(MDS) ,  rather  than  creating  entirely  new  software.  Although  the  current 
software  is  not  without  it's  problems,  we  feel  that  incremental  change 
is  the  only  realistic  approach  to  solving  them. 

3.  My  point  of  contact  is  SKCS(SS)  E.  Bures,  Code  N514,  AUTOVON 

564-6783  or  Commercial  (804)  444-6781. 


D.N. DOYLE 
By  direction 

Copy  to:  (w/o  ends) 

CINCLANTFLT  (N4) 

NAVMASSO  (01) 

NAVSEA  (04-TD) 

NAVSEA  (PMS-331) 
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DEPARTMENT  OF  THE  NAVY 
COMMANDER  NAVAL  SURFACE  FORCE 
UNITED  STATES  PACIFIC  FLEET 
SAN  DIEGO,  CALIFORNIA  92155-5035 


4400 

Ser  N7/7469 
15  AUG  199] 


From:  Commander,  Naval  Surface  Force,  U.  S.  Pacific  Fleet 

To:  Commander,  Naval  Supply  Systems  Command 

Subj  SNAP  II  SUPPLY  AND  FINANCIAL  MANAGEMENT  SYSTEM  FUNCTIONAL 
ASSESSMENT 


Ref:  (a)  COMNAVSUPSYSCOM  Itr  0332  4400  of  24  May  1991 


Enel : 


(1)  SNAP  II  Supply  and  Financial  Management  Reports  Analysis 

(2)  Type  Commander  SNAP  II  Supply  and  Financial  Functional 
Evaluation 

(3)  Type  Commander  SNAP  II  Supply  and  Financial  Functional  Needs 
Assessment 

(4)  Concept  of  Operations 


1.  Pursuant  to  agreements  made  during  the  April  1991  Functional  Policy 
Council,  reference  (a)  provided  a  matrix  of  afloat  business  system 
applications  for  review.  In  addition,  reference  (a)  forwarded 
questionnaires  in  regard  to  each  business  application  now  included  in 
the  current  5.10  release,  for  those  not  now  automated  in  SFM  5.10,  and 
with  regard  to  SNAP  II  Supply  and  Financial  Management  Reports.  As 
requested  by  reference  (a),  enclosures  (1),  (2),  and  (3)  have  been 
completed  and  are  returned. 


2.  Enclosures  (1),  (2),  and  (3)  were  reviewed  and  completed  by  members 
of  COMNAVSURFPAC ' s  Supply  Maintenance  Mobile  Training  Team  (SMTT) ,  all 
experts  in  shipboard/ staff  applications  of  SNAP  II  SFM  and  MDS.  SMTT 
comments  are  reflected  in  pencil  on  each  questionnaire.  Having 
developed  their  expertise  in  the  shipboard  environment,  the  comments 
provided  in  pencil  on  enclosures  (I),  (2),  and  (3)  are  necessarily 
bounded  by  existing  SNAP  II  SFM/MDS  environmental  constraints. 


3.  Subsequent  to  SMTT  review  and  comment,  the  enclosures  (2)  and  (3) 
questionnaires  were  subjected  to  a  second  review  at  the  COMNAVSURFPAC 
management  (0-5/0-6)  level.  The  intent  of  this  second  review  was  to 
explore  business  application  development,  taking  into  consideration 
environmental  constraints  redefined  by  technological  advances  including, 
for  example,  analog  and/or  digitized  data  transmission  via  satellite. 

In  such  environment,  the  opportunities  for  ships  becoming  Transaction 
Item  Reporting  (TIR)  activities  are  significant.  Enclosure  (4)  provides 
the  applicable  concept  of  operations.  Through  such  advances 
considerable  workload  can  be  moved  ashore  to  pierside  support  activities 
while  continuing  only  those  functions  aboard  ship  that  directly 
contribute  to  shipboard  combat  capability.  Those 
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applications  which  have  potential  for  being  moved  ashore  through  the  TIR 
concept  have  been  appropriately  annotated  in  red  ink  for  consideration 
in  future  development . 

4.  COMNAVSURFPAC  Point  of  Contact  is  LT  S.  Smith,  SC,  USN,  Code 
714/SMTT,  A/V  526-5789/commercial.  (619)  556-5789  or  CAPT  R.  Gunderson, 
SC,  USN,  N7,  A/V  577-2410/commercial  (619)  437-2410. 


R .  H .  GUNDERSON 
By  direction 

Copy  to: 

CINCPACFLT  (41) 


2 
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The  concept  of  operations  proposed  in  paragraph  three  of  the  basic 
letter  incorporates  satellite  communications  technology  to  move  workload 
ashore  and  reduce  inventory  investment  afloat.  A  basic  outline  of  the 
concept  is  provided  as  follows: 

-  The  SNAP  II  SFM  file  as  it  exists  aboard  ship  today  will  be  moved 
ashore  to  the  Pierside  Support  Activity.  The  ship  will  be  furnished  with  an 
automated  inventory /location  file  showing  minimal  data  elements  to  include 
NSN,  Nomenclature,  On  Hand  balance,  and  location; 

-  The  ship  will  transmit  transaction  item  reports  via  satellite 
communications  at  scheduled  times  to  the  Pierside  Support  Activity.  Data  will 
include  receipt  and  issue  transactions,  DTO  requisitions,  and  responses  to 
specific  Pierside  Support  Activity  data  inquiry  (e  .  g. ,  location/count 
inventory  directives,  etc.)  transactions  previously  transmitted  to  the  ship 
via  satellite  communications. 

-  The  Pierside  Support  Activity  will  maintain  the  ship's  SNAP  II  SFM 
data  base,  generate  all  financial  reports /listings,  run  levels,  generate 
reorders/replenishment  requisitions,  process  ship  DTO  requisitions  into  the 
supply  system,  and  otherwise  dialogue  with  the  shore  supply  and  finance 
establishment  in  resolving  issues.  The  ship  will  be  responsible  for  issuing 
material  from  its  storerooms  and  receiving  material  into  its  storerooms,  and 
TIR'ing  such  transactions  to  the  Pierside  Support  Activity  via  satellite 
communications.  Transactions/adjustments  to  shipboard  inventory/location  file 
will  be  accomplished  by  TIR  from  the  Pierside  Support  Activity  via  satellite 
communications . 

-  Shipboard  issues,  receipts,  and  directed  inventories  would  be 
accomplished  using  barcode  scanning  equipment,  storing  all  transactions  f^r 
automatic  download  to  communications  equipment  and  transmission  via 
communications  satellite. 

Using  existing  technology,  this  concept  of  operations  significantly  simplifies 
the  afloat  storekeepers  daily  workload,  reducing  it  to  one  of  receiving, 
issuing,  inventorying  as  directed,  and  transmitting  data.  Workload  reductions 
afloat  would  be  used  to  realign  manpower  to  staff  Pierside  Support  Activities. 
Total  visibility  of  assets  afloat  would  also  provide  significant  opportunity 
for  inventory  investment  savings  afloat  (e.  g.,  insurance  items  need  no  longer 
be  stocked  in  every  COSAL  but  perhaps  in  only  one  COSAL  of  ships  operating  in 
close  proximity.) 

While  the  above  addresses  the  shipboard  repair  part /general  stores  SFM 
function,  it  has  equal  applicability  to  the  food  service/provisions,  ships 
store,  personnel,  and  disbursing  functions  as  well  as  to  various  Maintenance 
Data  System  functions. 
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4000 

Ser  N752/63410 
8  JUL  1991 

From:  Commander,  Naval  Surface  Force,  U.S.  Atlantic  Fleet 

To:  Commander,  Naval  Supply  Systems  Command 

Subj:  SNAP  II  SUPPLY  AND  FINANCIAL  MANAGEMENT  SYSTEM  (SFM) 

FUNCTIONAL  ASSESSMENT 

Ref:  (a)  COMNAVSUPSYSCOM  Itr  0332  44400  of  24  May  91 

End:  (1)  Type  Commander  SNAP  II  SFM  Functional  Evaluation 

(2)  Type  Commander  SNAP  II  SFM  Functional  Needs  Assessment 

(3)  Type  Commander  SNAP  II  SFM  Reports  Critique 

1.  In  accordance  with  reference  (a),  enclosures  (1)  through  (3)  are 
submitted  to  assist  in  completing  the  functional  assessment  of  SNAP 
Material  Management  Systems  for  future  afloat  use. 

2.  COMNAVSURFLANT  point  of  contact  SKCS(SW)  McGourn,  N7521,  commercial 
(804)  444-5816,  AUTOVON  564-5816. 


J.  W.  FREEMAN,  JR. 
By  direction 
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COMMANDER  SUBMARINE  FORCE 
UNITED  STATES  PACIFIC  FLEET 
PEARL  HARBOR,  HI  96860-6550 


4400 

Ser  5121/005008 
24  JUL  1991 

From:  Commander  Submarine  Force,  U.S.  Pacific  Fleet 
To;  Commander,  Naval  Supply  Systems  Command  (033) 

Subj  :  SNAP  II  SUPPLY  AND  FINANCIAL  MANAGEMENT  SYSTEM 

FUNCTIONAL  ASSESSMENT 

Ref:  (a)  COMNAVSUPSYSCOM  Itr  Ser  0332-4400  of  24  May  91 

Enel:  (1)  SNAP  II  Supply  and  Finaiicial  Management  Reports 

Analysis 

(2)  Type  Commander  SNAP  II  Supply  and  Financial  Functional  Evaluation 

1.  The  functional  assessment  enclosed  in  reference  (a)  has  been 
reviewed  and  is  returned  with  requested  responses  as  enclosures  (1)  and 
(2)  . 

2.  COMSUBPAC  point  of  contact  is  LT  Dana  Ivey  (Code  5121)  who  may  be 
reached  at  A/V  471-8111  or  COML  (808)  471-0464/9034. 


D.  R.  LENGKEEK 
By  direction 
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4400 

Ser  713/7059 
30  JUL  1991 

From:  Commander,  Naval  Surface  Force,  U.S.  Pacific  Fleet 

To:  Commander,  Naval  Supply  Systems  Command 

Sub  j  :  SUADPS  RELEASE  3  FUNCTIONAL  ASSESSMENT 

Ref:  (a)  COMNAVSUPSYSCOM  Itr  0332  4400  of  24  May  91 

Enel:  (1)  Type  Commander  SUADPS  Functional  Evaluation 

(2)  Type  Commander  SUADPS  Functional  Needs  Assessment 

(3)  T'noe  Commander  SUADPS  Reports  Critique 

1.  The  SUADPS  Functional  Evaluations,  Needs  Assessments,  and  Report 
Critiques  forwarded  by  reference  (a)  were  reviewed  in  depth  by  five 
COMNAVSURFPAC  evaluators,  representing  over  70  years  of  SUADPS 
experience.  Enclosures  (1)  through  (3)  are  a  consolidated  input,  based 
on  the  evaluators'  review. 

2.  In  general,  the  evaluators  found  this  functional  assessment  process 
to  be  difficult,  at  best.  Also,  the  evaluators  found  that  a  significant 
number  of  applications  which  are  identified  as  currently  being  available 
in  SUADPS  are,  in  fact,  not  available.  The  reverse  situation  was  also 
found  to  exist.  The  fact  that  our  evaluators  could  not  reach  the  same 
conclusion  as  NAVMASSO  as  to  whether  or  not  an  application  is  available 
in  SUADPS,  supports  our  finding  that  it  is  difficult  to  interpret  the 
meaning  of  the  functions  and  applications.  In  short,  any  conclusions 
drawn  from  this  study  must  be  viewed  with  caution.  The  following 
comments  apply: 

a.  Numerous  business  functions  and/or  applications  could  not  be 
interpreted  as  to  their  actual  meaning; 

b.  Functions  and  applications  as  stated,  often  duplicated  or 
overlapped  other  applications;  and 

c.  Many  of  the  business  applications  "considered  necessary"  for  modern 
afloat  supply  operations  are  defined  in  terms  of  current  SUADPS  terminology 
and  are  questionable  "required"  applications.  {Example:  Validation  Tables, 
Local  Constants,  Counters.)  These  applications  are  required  in  our  current 
system  design,  but  may  be  unnecessary  in  a  redesigned  system  with  different 
goals  and  objectives. 

3.  Interestingly,  the  evaluation  shows  that  individually,  many  of  the 
SUADPS  applications  work  as  advertised.  But  as  evidenced  from  our 
operational  experience,  there  are  numerous  problems  when  these  inter-related 
applications  are  combined.  There  is  no  synergy  in  the  current  process. 

This  is  due  in  part  to  the  complexity  of  Navy  Stock  Fund  financial  reporting 
requirements  and  the  computer  programming  required  in  SUADPS  to  support  this 
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effort.  This,  coupled  with  the  level  of  knowledge  required  to  understand 
and  manage  this  system  are  the  root  of  our  problems.  We  must  simplify, 
simplify,  simplify! 

As  stated  numerous  times  in  the  past,  to  simplify  the  process  we  must 
use  today's  technology  and  link  afloat  data  bases  with  shore-based  systems 
to  utilize  the  synergistic  effect  of  shared  information.  No  one  is  debating 
the  fact  that  there  are  obviously  good  ideas  in  SUADPS,  OMMS,  IMMS/MRMS,  and 
SNAP  II  SFM/MDS,  along  with  other  shipboard  AIS's.  But,  as  agreed  upon  at 
the  January  1987  NjMAIP,  a  zero  based  redesign  is  the  only  way  we  can  get 
away  from  making  an  overly  complex  system  even  more  complex  by  applying 
bandaids  to  continually  correct  system  deficiencies.  Acknowledging  that  we 
have  already  embarked  on  one  grandiose  zero  based  redesign  effort  which 
failed  because  of  it's  own  weight  and  that  the  chance  of  starting  another 
zero  based  redesign  to  achieve  an  optimal  solution  is  unlikely,  than  we  have 
to  do  something  to  help  people  better  understand  the  system  in  place.  To  do 
this,  we  ought  to  capitalize  on  the  effort  that  has  already  gone  into  the 
zero  based  redesign  and  list  the  information  that  people  have  already 
identified  as  being  the  information  they  want  to  derive.  Then  a  matrix  can 
be  constructed  showing  the  desired  information  product  on  the  left  and  the 
existing  business  functions  on  the  right  which  can  be  utilized  to  provide 
the  desired  information.  Business  functions  that  do  not  contribute  to  a 
specific  desired  information  product  should  be  candidates  for  elimination. 
The  resulting  business  functions  can  then  be  evaluated  to  see  if  they  can  be 
simplified  or  if  the  burden  of  using  them  exceeds  the  value  of  the 
information  derived.  In  this  way,  the  business  functions  can  be  evaluated 
in  context  of  the  role  they  play  in  the  overall  system.  To  try  to  evaluate 
the  business  functions  as  stand  alone  entities  is  confusing  to  all  concerned 
and  can  lead  to  a  lack  of  coordination  and  agreement  on  how  to  interpret  the 
questions  and  therefore  to  a  data  base  of  answers  which  may  be  seriously 
misinterpreted. 

5.  COMNAVSURFPAC  point  of  contact  is  CDR  C.  A.  Toledo,  SC,  USN,  Code  73^, 
or  CAPT  G.  Locke,  USMC,  Code  713A  at  AUTOVON  526-5748  or  commercial  (619) 
556-5748, 


K.  W.  LIBBY 
By  direction 


2 
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UNITED  STATES  MARINE  CORPS 
2d  MARINE  AIRCRAFT  WING,  FMF,  ATLANTIC 
MARINE  CORPS  AIR  STATION 
CHERRY  POINT,  NORTH  CAROLINA  28533-6001 

IN  REPLY  REFER 
TO 

4400 
ALD/srf 
15  Jul  1991 


From:  Commanding  General,  Second  Marine  Aircraft  Wing 

To:  Command-,  Naval  Supply  System  Command  (0332), 

Washington,  DC  20376-5000 

Sub  j  :  SUADPS  RELEASE  3  FUNCTIONAL  ASSESSMENT  RESPONSE 

Ref:  Commander,  Naval  Supply  Systems  Command,  0332  over  4400 

dated  24  May  1551 

Enel:  (1)  Type  Commander  SUADPS  Functional  Evaluation 

(2)  Type  Commander  SUADPS  Functional  Needs  Assessment 

(3)  Type  Commander  SUADPS  Reports  Critique 

1.  As  requested,  the  enclosures  have  been  reviewed  and  annotated. 

2.  Please  note  that  this  package  was  reviewed  from  a  Marine  aviation 
logistics  perspective  which  includes  both  NALCOMIS  and  SUADPS-RT 
processing  systems.  The  on-line  help  function  in  NALCOMIS  is  a  very 
valuable  tool.  This  function  does  not  exist  in  SUADPS-RT  but  should  be 
implemented  in  any  follow-on  system. 

3.  2d  MAW  POC:  CWO-2  S.  Foster,  ALD-L,  Av:  582-5111/3933. 


M.  C.  SKIPPER 
By  direction 


Copy  to: 

CMC  {ASL-32) 
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DEPARTMENT  OF  THE  NAVY 
COMMANDER  NAVAl  AIR  FORCE 
UNITED  STATES  PACIFIC  FLEET 
NAVAL  AIR  STATION,  NORTH  ISLAND 
SAN  DIEGO,  CALIFORNIA  92135-5100 
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4400 

Ser  453/6561 

06  AUG  1991 

• 

From: 

To: 

Commander  Naval  Air  Force,  U.S.  Pacific  Fleet 

Commander,  Naval  Supply  Systems  Command 

Sub  j  : 

SUADPS  RELEASE  3  FUNCTIONAL  ASSESSMENT 

Ref : 

(a)  COMNAVSUPSYSCOM  Itr  0332  4400  of  24  May  91 

End : 

(1)  Type  Commander  SUADPS  Functional  Evaluation 

(2)  Type  Commander  SUADPS  Functional  Needs  Assessment 

(3)  Type  Commander  SUADPS  Reports  Critique 

1.  The  SUADPS  products  forwarded  by  reference  (a)  have  been  reviewed 
and  are  being  returned  as  enclosures  (I)  through  (3).  The  following 
comments  apply: 


a.  Many  of  the  business  functions  and/or  applications  were  not 
understood  by  anyone  on  this  staff;  the  package  was  reviewed  by  two 
Senior  and  two  Master  Chief  Petty  Officers,  a  GS-12  Financial  Analyst,  a 
Lieutenant  (former  stock  control  officer)  and  two  former  SUADPS 
experienced  Limited  Duty  Officers,  one  was  a  Lieutenant  Commander  with 
31  years  experience  and  the  second  was  a  Lieutenant  with  27  years 
experience.  The  difficulty  of  developing  a  comprehensive  and  explicit 
functional  evaluation  for  a  baseline  review  of  our  current  business 
applications  is  appreciated,  however  the  one  or  two  word  descriptions 
provided  for  the  function,  sub-function  and  application  titles  were  much 
too  general  in  nature  resulting  in  a  lot  of  confusion  about  what 
function  actually  was  being  analyzed. 

b.  Functions  and  applications  were  frequently  either  duplicated  or 
contained  within  other  applications. 

c.  Many  of  the  applications  do  not  appear  to  be  related  to  SUADPS 
Release  3  or  any  other  management  system  of  the  future  which  will  replace 
Release  3  (e.g.  SAMS,  ADMIN  and  Ship's  Store  Returns).  The  fact  that  these 
applications  are  performed  aboard  ships  does  not  make  them  viable  candidates 
for  inclusion  in  a  mainframe  computer  Supply  and  Financial  Management  System 
of  the  future  cannot  and  should  not  be  an  all  inclusive  AIS  containing  every 
conceivable  function  performed  aboard  ships.  Not  only  should  some  of  those 
functions  be  properly  accomplished  manually,  but  also  those  functions  that  are 
stand  alone  and  can  be  performed  on  a  micro-computer  system  should  remain  on 
micro  computers. 

2.  The  objective  of  any  future  inventory /financial  management  system  should 
be  to  enable  the  shipboard  storekeeper  to  concentrate  his  efforts  on  accurate 
receipt,  issue  and  inventory 
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control  procedures  and  not  have  to  worry  whether  the  appropriation  data  for 
another  ship  he  has  just  made  a  transfer  to  is  contained  in  validation  tables. 
Those  financial  applications  can  and  should  be  performed  ashore  with  existing 
technology  used  to  communicate  to  the  shore  facility  what  material 
transactions  have  occurred. 

3.  The  tremendous  effort  put  into  developing  this  baseline  review  is  obvious; 
the  validity  of  the  results  are  certain  to  be  suspect  given  the  ambiguities  of 
the  functional  descriptions.  Informal  conversations  with  COMNAVSURFPAC  and 
COMNAVAIRLANT  have  expressed  the  same  concern  and  frustration  of  attempting  to 
design  software  by  mail.  A  working  level  (one  or  two  experts  per  TYCOM  and 
CDA)  conference  to  review  the  results  and  clear  up  any  lingering  concerns  to 
be  the  next  step  in  this  process. 

4.  COMNAVAIRPAC  point  of  contact  is  CDR  R.  A.  Boyd,  Code  45  or  LT 

E.  S.  Walters,  Code  453  at  AUTOVON  735-1020  or  Commercial  (619)  545-1020. 


R.  A,  BOYD 
By  direction 
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DEPARTMENT  OF  THE  NAVY 

COMMANDER  SUBMARINE  FORCE 
U.S,  ATLANTIC  FLEET 
NORFOLK,  VIRGINIA  23511-5230 


4400 

Ser  N531/2153 
16  AUG  1991 

From;  Commander  Submarine  Force,  U.S.  Atlantic  Fleet  Commander, 

To:  Commander,  Naval  Supply  Systems  Command  (SUP  033) 

Subj;  SUADPS  RELEASE  3  FUNCTIONAL  ASSESSMENT 

Ref:  (a)  NAVSUP  Itr  Ser  0332/4400  of  24  May  91 

Enel:  (1)  Type  Commander  SUADPS  Functional  Evaluation 

(2)  Type  Commander  SUADPS  Functional  Needs  Assessment 

(3)  Type  Commander  SUADPS  Reports  Critique 

1.  As  requested  by  reference  (a),  enclosures  (1)  through  (3)  are 
forwarded. 

2.  Request  COMSUBLANT  be  provided  with  summary  results  of  the  Type 
Commanders  SUADPS  Functional  Assessment  no  later  than  30  September  1991. 


T.  0,  DUFFEY 
By  direction 
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UNITED  STATES  PACIFIC  FLEET 
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4400 

Ser  5113/004436 
27  JUN  1991 

From:  Commander  Submarine  Force,  U.S.  Pacific  Fleet 

To:  Commander,  Naval  Supply  Systems  Command 

Sub  j  :  SUADPS  RELEASE  3  FUNCTIONAL  ASSESSMENT 

Ref:  (a)  COMNAVSUPSYSCOM  Itr  Ser  0332-4400  of  24  May  91 

Enel:  (1)  Applications  Found  in  Various  Afloat  Business  Systems 

Questionnaires  and  Type  Commander  SUADPS  Functional  Evaluations 

1.  The  functional  assessment  enclosed  in  reference  (a)  has  been 
reviewed  and  is  returned  as  enclosure  (1) . 

2.  COMSUBPAC  point  of  contact  is  LT  Jim  Barnard  (Code  5113),  who  may 
be  reached  at  A/V  471-8111  or  COML  (808)  471-0464/474-5538. 


D.  R.  LENGKEEK 
By  direction 
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COMMANDER  NAVAL  SURFACE  FORCE 
UNITED  STATES  ATLANTIC  FLEET 
NORFOLK,  VIRGINIA  23511-5215 


4400 

Ser  N72/09579 
8  AUG  1991 

From:  Commander,  Naval  Surface  Force,  U.S.  Atlantic  Fleet 

To:  Commander,  Naval  Supply  Systems  Command  (Code  0332) 

Sub  j  :  SUADPS-RT  REL  3 . 0  FUNCTIONAL  ASSESSMENT 

Ref:  (a)  COMNAVSUPSYSCOM  0332  4400  of  24  May  91 

Enel:  (I)  Response  Matrix 

(2)  SUADPS  Functional  Evaluation  Work  Sheets 

(3)  SUADPS  Functional  Needs  Assessment  Work  Sheets 

(4)  SUADPS  Reports  Critique 

1.  As  requested  by  reference  (a),  enclosures  (1)  through  (4)  are 
forwarded  as  input  to  the, 'comprehensive  evaluation  of  SUADPS. 

2.  The  Response  Matrix,  enclosure  (1),  is  provided  as  a  summary  sheet 
of  responses  to  key  questions  as  viewed  from  the  TYCOM' s  perspective. 
Note  that  the  column  addressed  as:  (1)  Non-applicable  (N/A)  contains 
responses  to  functionality  not  intended  for  SUADPS  processing  and  (2) 
Insufficient  Information  contains  responses  to  functionality  that  lacked 
sufficient  descriptive  information  to  clearly  determine  its  intended 
purpose  or  processing  goals. 

3.  My  point  of  contact  for  further  information  is  LT  D.  Lendle  (N723), 
AUTOVON  564-5882  or  commercial  (804)  444-5882,  FAX  number  is  (804)  445- 
2236. 


J.  E.  COOK 
By  direction 
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CNSL  RESPONSE  MATRIX 


(1)  TYCOM  FUNCTIONAL  EVALUATIONj. 
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